CSC/ECE 517 Fall 2009/wiki2 4 dn

A large fraction of the if-statements in o-o programs could be replaced by uses of polymorphism, which would lead to more modular and maintainable programs. Explain why if-statements are error prone if there is any chance that future development may require them to change. Give examples of if-statements that can be replaced by elegant uses of polymorphism, trying to find some useful replacements that are not obvious. Concentrate on polymorphism, not other reasons for avoiding use of ifs.

The If Statement

The if-then statement is the most basic of all the control flow statements. It tells a program to execute a certain section of code only if a particular test evaluates to true.

if (daytime is morning)
{
  print "good morning"
}
else if (daytime is afternoon)
{
  print "good afternoon"
}
....
....

When and why are if-statements error prone?

Maintainability and Extensibility

Methods that use conditional if-statements can be hard to maintain and extend.

Public class  operator
{
   public int calculate(int a, int b)
   {
      if (operator = "+")
      {
         result = a+b
      }
      else if(operator = "-")
      {
         result = a-b
      }
    }
}

In the above example if the programmer wanted to extend her code to handle multiplication, division and the mod operation then she would have to write an explicit conditional statement to handle each of these. If the condition is checked in multiple places then the programmer will have to add the additional conditional statement in each of these places. This not only results in duplication of code but is also highly error prone.

Testing

Sometimes in a program the same condition may have to be checked in multiple places.

if(flag is enabled)
{
  read a
}
else if(flag is not enabled)
{
  read b
}

.....
.....

if(flag is enabled)
{
 write a 
}
else if(flag is not enabled)
{
 write b
}

In the above example, flag is checked multiple times. This scenario can be particularly difficult for testing and debugging because, the progaram needs to read a and write a or read b and write b. The program should not read a and write b or read b and write a. If the condition needs to be checked more than twice then testing and debugging becomes even more complicated.

If statements and Polymorphism

Most if-statements such as the ones shown above can be replaced with polymorphism.

In object-oriented programming, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class. More specifically, it is the ability to redefine methods for derived classes.

Why should if-statements be replaced with polymorphism?

The essence of polymorphism is that it allows a programmer to avoid writing an explicit conditional for an object whose behaviour varies depending on its type. Therefore object oriented programs have very few if-statements that switch on type strings.

Polymorphism allows a programmer to add new types very easily. This is particularly useful when the same set of conditions appear in many places in a program. The programmer has to find and update all the conditionals with the new type. But, with polymorphism you can just add a new sub class and provide the appropriate methods. Clients of the class dont need to know about the subclasses. This decreases dependencies in your application and makes updating easier.

When should if-statements be replaced with polymorphism?

All if-statemetns cannot be replaced with polymorphism. If-statments must be used when basic comparisons such as <,>,==, != are done.

Polymorphism should be used instead of conditionals-

• If an object should behave differenty based on its state.
• If the same condition has to be checked in multiple places.

Examples of replacing if statements with polymorphism

Example 1: When behaviour changes depending on the type of the object

The calculate function shown above which uses if statements to perform arithmatic opertaions can be re-written as follows using polymorphism:

public abstract class Operator
{    
   public abstract int calculate(int x, int y);
}
public class Add : Operator
{    
   public int calculate(int x, int y)
   {        
     return x + y;   
   }
}
public class Subtract : Operator
{
  public int calculate(int x,int y)
  {
    return x-y;
  }
}

Here by making the calculate method abstract in the Operator class, we are enabling it to be overridden by the calculate methods in classes Add and Subtract. By doing this the functionality of each of the operator type is separated and therfore dependencies are minimised. Hence, a programmer can not only make updates eaily but can also add new types of operators without actually accessing the source code.

Therefore, when you have a conditional that changes behaviour depending on the type of an object, move each leg of the conditional to a subclass and make the original method abstract.Ref