I was doing some reading on the weekend and came across some really good thoughts on how to make decisions in code – but not by using conventional if or select branching mechanisms or others that masquerade as flow control statements under other guises.<\/p>\n\n\n\n
There’s a whole movement for “if-less programming”.<\/p>\n\n\n\n
And it fits very well with using OOP and the capabilities of polymorphism in ways that make your code clearer and easier to maintain and extend.<\/p>\n\n\n\n
Let’s say you have a class that represents vehicles. Your program permits you to have many types of vehicles with various capabilities. And somewhere in that class that represents a vehicle you might have code like :<\/p>\n\n\n\n
Function calculateMaximumWeightCapacity() as Double\n if ( vehicleType = \"Transport\" ) then\n \/\/ we have to account for the fact this has 18 wheels and 5 axles\n elseif ( vehicleType = \"Truck\" ) then\n \/\/ we have to account for what kind of light duty truck this is\n elseif ( vehicleType = \"Car\" ) then\n \/\/ we have to account for what kind of car this is as a mini cant\n \/\/ carry as much as a impala\n end if\nEnd Function<\/code><\/pre>\n\n\n\nYes this is contrived but you get the point<\/p>\n\n\n\n
IF you have classes that display this kind of code then you probably should consider using polymorphism in a way it can make you life easier.<\/p>\n\n\n\n
In your application, if you have this kind of code, then EVERY time you want to add a new kind of vehicle you have code to adjust. You’ll need to update every possible place this kind of selection goes on. And if you miss one you have bugs.<\/p>\n\n\n\n
If However we used polymorphism to help us we could be sure that any time we added a new vehicle type we definitely covered all the required functionality AND that we didnt have to adjust a lot of code in many places.(1)<\/p>\n\n\n\n
Instead if we had<\/p>\n\n\n\n
Class Vehicle\n Private Sub Constructor()\n \/\/ this is so we make this class \"abstract\" and \n \/\/ you cannot create new vehicles - you MUST create \n \/\/ instances of subclasses only\n End Sub\n\n Function calculateMaximumWeightCapacity() as Double\n \/\/ since we have NO way to FORCE a subclass to override this \n \/\/ we put a break in here so we can figure out which subclass \n \/\/ did NOT override this\n BREAK\n End Function\nEnd Class\n\nClass Transport\n Inherits Vehicle\n Function calculateMaximumWeightCapacity() as Double\n \/\/ we have to account for the fact this has 18 wheels and 5 axles\n return 30000 \/\/ just for fun !\n End Function\nEnd Class\n\nClass Car\n Inherits Vehicle \nEnd Class\n\nClass Mini\n Inherits Car\n Function calculateMaximumWeightCapacity() as Double\n \/\/ we have to account for what kind of car this is as a mini cant\n \/\/ carry as much as a impala\n return 500\n End Function\nEnd Class\n\nClass Impala\n Inherits Car\n Function calculateMaximumWeightCapacity() as Double\n \/\/ we have to account for what kind of car this is as a mini cant\n \/\/ carry as much as a impala\n return 1000\n End Function\nEnd Class\n\n.. and so on ...<\/code><\/pre>\n\n\n\nAnd this gets rid of the need to use an IF to test what kind of vehicle it is to determine how to compute the weight. The specific subclass just does it knowing that its a transport, a truck, a mini or an impala.<\/p>\n\n\n\n
Function calculateMaximumWeightCapacity() as Double\n return self.calculateMaximumWeightCapacity()\nEnd Function\n<\/code><\/pre>\n\n\n\nNote that this code is much simpler to follow.<\/p>\n\n\n\n
And when you need to add a new kind of vehicle you add a new class type, recompile and off your program goes because you havent had to hunt around and find all the places where you need to check vehicle types and maybe introduce new bugs.<\/p>\n\n\n\n
Polymorphism is definitely your friend here.<\/p>\n\n\n\n
<\/p>\n\n\n\n
footnotes <\/p>\n\n\n\n
(1) there are some things that Xojo does NOT provide that would make life simpler. A means of forcing a subclass to override a specific method defined in a super class does NOT exist. IF we use a base class we can only catch that a subclass has not overridden a method. Some languages have a means for a base class to define a method that subclasses MUST implement. Xojo does not.<\/p>\n\n\n\n
Its possible to use an interface to force implementors of an interface to implement a method BUT this MAY be the wrong approach for the specific problem.<\/p>\n","protected":false},"excerpt":{"rendered":"
I was doing some reading on the weekend and came across some really good thoughts on how to make decisions in code – but not by using conventional if or select branching mechanisms or others that masquerade as flow control statements under other guises. There’s a whole movement for “if-less programming”. And it fits very … <\/p>\n