Created December 23, 2009
Last updated December 23, 2009
[ Japanese | English ]

Polymorphism

  In this page ,I will explain the polymorphism. And I will explain the merit , demerit and usage of it.

  About the merit, first of all, about the point that "If" statements are not needed , I will explain it from the module cohesion and coupling in detail. There are cases that the polymorphism must be used ( for example, event processing ), and I will explain it.
  About the usage of the polymorphism, there are the design pattern of GoF , and I will explain it.

Attention : If you don't understand the module cohesion and coupling , please read "Object-oriented and the Modele Cohesion and the Module Coupling - Dharma's Excel VBA" before reading this page.

1. What is the polymorphism?
2. The merit and demerit of the polymorphism
3. Cases that the polymorphism must be used
4. The usage of the polymorphism
5. Reference


1. What is the polymorphism?

  The polymorphism is a mechanism that when the method of object is called , movement of if is changed by the type of it.

  For the time being , please read the following class diagram and sample source code. If you execute this sample source code, please pay attention to your Excel VBA vertion. The version is need 6 or more. If your Excel Version is 97 or your Excel is mac edtion , you cannot execute it.


Figure 1 - The class diagram of the polymorphism sample


Class0 ( Class Module )

Option Explicit
Public Sub
printClassName()

End Sub



Class1 ( Class Module )

Option Explicit
Implements Class0

Private Sub Class0_printClassName()
    Debug.Print "Class1"
End Sub



Class2 ( Class Module )

Option Explicit
Implements
Class0

Private Sub Class0_printClassName()
    Debug.Print "Class2"
End Sub



Class3 ( Class Module )

Option Explicit
Implements
Class0

Private Sub Class0_printClassName()
    Debug.Print "Class3"
End Sub


 
Module1 ( Standard Module )

Option Explicit

Public Sub main()

    Dim objs(1 To 3) As Class0
    Dim i As Integer

    Set objs(1) = New Class1
    Set objs(2) = New Class2
    Set objs(3) = New Class3

    For i = LBound(objs) To UBound(objs)
        Call objs(i).printClassName
    Next
   
End Sub



Execution result ( Immediate Window )

Class1
Class2
Class3


At the standard module, the "Call objs(i).printClassName" called the "printClassName" method without considering contents of the "objs" array.
And , the execution result ( result of main method at the standard module ) is according to definition of the "printClassName" method that is defined at each class module.
 
Back to Top

2. The merit and demerit of the polymorphism

  I will explain the point that "If" statment is not needed.
(It is difficult to explain. Because , in the VBA , if you use the Object type , you can realize the same.)
  If the polymorphism is not used in the above-mentioned source code ( standard module ) , you must program the following in the "For" statement.
  If TypeName(objs(i)) = "Class1" Then
    '...
  Else If TypeName(objs(i)) = "Class2" Then
    '...
  Else If TypeName(objs(i)) = "Class3" Then
    '...
  End If


  If this program is written , the readable of source code becomes worse. And the cost and time of the test of the program becomes more increased. ( If you don't know the test , please read the White-box testing.)
  Then , I want you to remember the module cohesion, and I think that this is the Logical cohesion.
( I think that the cohesion of the Module1 become worse. )
And , the point that the Module1 is coupled the Class1 , Class2 and Class3 that is a sub-class of the Class0 is bad.
When a sub-class of the Class0 become increase, if there is only one place that "if" statement is used , you can maintain the program. But , if there are 1,000 place , I think that you cannot maintain it. ( I think that you will leak the maintenance. )

The summary of the merit :
  1. The source code using the Class0 become decreased.
  2. The cost and time of the test become decreased.
  3. The module cohision become better , and the module coupling become lower.


  Next , I will explain the demerit.
  First of all , the Class0 becomes needed. In short , the line of the source code become increased.
  Next . I want you to think the following case.
  Afterwards, you hit upon that the Class4 is needed.
  You design the Class4 , then you hit upon that the "printClassName" method of the Class4 needs arguments 1. But it of the Class0 doesn't have arguments. What do you do ? If you increase arguments of the "printClassName" method of the Class0 , you must maintain the Class1, Class2 and Class3. And If the method is used by 1,000 place, the cost and time of the maintenance become very more.
  Like this , afterwards , I offen hit opon the insufficiency of the arguments of the override method and the inconsistency of the return value type. This is really ...
  Of course, I securely design in order not to become so. But for that reason , the design time become more increased. If there are 1,000 place using the "printClassMethod" , I think that you mast surely use the polymorphism. But if there is one plase , I think that you should not use 2.


  The following Table 1 is the summary of the merit and demerit of the polymorphism.

Table 1 - The summary of the merit and demerit of the polymorphism
The merit of the polymorphism
The demerit of the polymorphism
1. You can decrease the source code of the class using the interface.
2. You can decrease the "If" statements. and you can decrease the cost and time of the test of the class using the interface.
3. You can design the higher cohesion class using the interface. And you can design lower coupling.
4. The class using the interface is not needed to modify when the number of the sub-class is increased.
1. The cost and time is increased by designing and programming the interface.
2. If the design of the interface is bad , you cannot correspond when the number of the sub-class is increased.
3. the cost and time is increased because of the evasion of 2.


-----
Note.
1: When saying more accurately , "You design the Class4 , you hit opon that the classes designe cannot keep the Liskov substitution principle."
2: This contents is written the "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)".
Back to Top

3. Cases that the polymorphism must be used

  If the polymorphism is not used, there are the things that can not be realized. In this case, you must use the polymorphism.

  The case is a case that you design the framework and a case that you use the framework.
  For example , the event processing ( Generally, this is programed by the Observer pattern . But in the VBA (note. VBA version is 6 or more) , this is programed by the "Event" statement. ) and so on.
  
  I think that there are some other. Please search.
Back to Top

4. The usage of the polymorphism

  About the usage of the polymorphism , in the design pattern of the GoF , I will introduce the pattern that the polymorphism is related. There are only 23 pattern in the design pattern of the GoF , but as there are a lot of pattern that the polymorphism is related , I cannot introduce everything. I'm sorry.


-----
Note.
1: Because I cannot examine everything.
Back to Top

5. Reference

The following tables are pages that I referred to create this page.

No.

Linked Website Name

Description

Linked date

1

Design Patterns (book) - Wikipedia, the free encyclopedia This page introduce the design pattern of the GoF. December 23, 2009

2

Polymorphism in object-oriented programming - Wikipedia, the free encyclopedia This page explans the polymorphism. December 23, 2009

No.

Author

Book Name

ISBN

1

Craig Larman Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) 978-0137488803

Prev Up Next  Top
Back to Top

I doesn't assume the responsibility of any damage that occurs because of the use of this page.

Microsoft ,Windows ,Visual Basic and Excel are registered trademarks of Microsoft Corporation in the United States and other countries.
Visual Basic® for Applications may represent a VBA.
Mac ,Mac OS ,Mac OS X ,AppleScript are trademarks of Apple Inc., registerd in the U.S. and other countries.
Sun, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun logo, the Sun Microsystems Computer Corporation logo, Solaris, Java, JavaSoft, JavaScript, HotJava, JDK, and all Java-based trademarks or logos are trademarks or registered trademarks of Sun Microsystems, Inc.
Other brands and their products are trademarks or registered trademarks of their respective holders and should be noted as such.

The author of this page and these companies do not have any relationship.