CSC/ECE 517 Fall 2009/wiki2 4 va
Introduction
The If statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in FORTRAN in a form of an arithmetic If statement back in 1957. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a logical If statement (if-then-else), the one that is still widely used to this day.
The logical If statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the If statement is more suitable for structured programming, most today's object-oriented languages have more sophisticated mechanisms to replace it. One of such approaches is a use of polymorphism.
This paper will discuss ways in which a polymorphism technique can be applied to replace the If control structures, pros and cons of both, and will demonstrate some examples written in Ruby language.
What is wrong with using If statements?
Most of the time, a correctly written IF statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:
i = 1 # or any other number if i >= 0 puts "greater or equal to zero" elsif i < 0 puts "less than zero" else puts "will never run!!!!" end
As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of If statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.
Example using IF statements
Let's consider a simple code that would illustrate a use of IF statement in an object-oriented language. First, we define a parent class, Vehicle, and two child classes - Car and Truck. We would then ask a user to choose which of the two classes they would like to initialize. Depending on their selection, the code would look up and suggest a type of fuel that would work with the selected vehicle.
Below is a Ruby code that implements the above utilizing the IF statement:
class Vehicle
def initialize
puts "I am a vehicle"
end
end
class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end
class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end
class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
If we respond with a "Car", the output would look as follows:
Do you have a Car or a Truck? Car I am a vehicle I am a passenger car I like 87 octane gasoline
One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles grows further. For instance, let's imagine we decided to add two new vehicle types, Motorcycle and Bicycle. In order to support this addition, we would need to add two new classes, as well as to modify the IF statement (or, better to replace it with a more appropriate conditional, such as case.)
Example of IF replaced by polymorphism
Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named "get_type_of_fuel" in all child classes. Similar to the earlier example, the caller of the method is has no way of knowing which class will be chosen as it would be a run-time decision.
Again, we will use Ruby code to demonstrate the new approach:
class Vehicle
def initialize
puts "I am a vehicle"
end
end
class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
def get_type_of_fuel
"I like 87 octane gasoline"
end
end
class Truck < Vehicle
def initialize
super
puts "I am a truck"
end
def get_type_of_fuel
"I like diesel"
end
end
class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
If a "Car" is selected, the output would remain the same:
Do you have a Car or a Truck? Car I am a vehicle I am a passenger car I like 87 octane gasoline
However, the maintainability of the application has improved. For instance, as we add new Vehicle types, the class Driver would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a "get_type_of_fuel" method).
Conclusion
xxxxx