Polymorphism in C++
|| Views: 1907 | 5-11-2010, 07:55 | Category : Other
Polymorphism means that the same thing can exist in two forms. This is an important characteristic of true object oriented design – which means that one could develop good OO design with data abstraction and inheritance, but the real power of object oriented design seems to surface when polymorphism is used.
Why would a design want the same entity to behave differently at different times ? On first thoughts, this appears more confusing than anything useful.
In C++, polymorphism means that if the same message is sent to different objects, the object’s behavior depends on the nature of the object itself. This is sort of obvious for completely different objects, but the concept starts making sense when combined with inheritance.
In object oriented practice, it is common that class objects are manipulated through a pointer or reference to an abstract base class. The abstract base class hence defines an interface to all the classes that are derived from it. Note that the abstract base class itself cannot be instantiated, and serves to provide another level of separation between interface specification (in abstact base class) and implementation (in derived classes).
A classic example is how area is calculated on different shapes. We define an abstact base class shape and derive two classes – rectangle and circle from it. An area() method defined in the base class will have to be implemented differently in rectangle and circle, since it has to be calculated differently. This is an example of polymorphic behavior, and in C++, this is implemented using virtual member functions. The area() member function is defined virtual in the base class, which signals to the compiler that this member function has to be invoked from the correct derived class at run time. This is indeed a run time decision, since as we saw earlier, objects may be manipulated using the base class pointer, and which derived class member function is to be invoked depends on which derived class pointer has been assigned to the base class pointer.
This also brings in the concept of late binding (run time binding), since the above association to the area member function can only be done at run time. The compiler will have to insert extra code to do the late binding, which adds in a little runtime overhead. For embedded systems with very constrained resources, late binding may introduce unacceptable overheads. In most systems with reasonable resources, this may not be a significant problem, but it is important to be aware of the impact of using this advanced feature of C++.
Read also: Rails' ActiveRecord, Reactor, Illudium: All backwords for OO.ActiveRecord has (bad!) consequences.I Don't Like RailsC++ Development servicesCFCUnit + FlexUnit How-To: No excuses now!