When you stady the object-oriented for the first , I thin that the thing that you understand is the inheritance. But I think that you should understand about the class and object first...
The inheritance is easy...
And , We can understand the "incremental programming" without understanding the class , object and so on ...
But , this "incremental programming" is wrong. Because , this is a idea for process. In short , if you only think the "incremental programming" , I think that you do the same mistake as the POA (Process-Oriented Approach) .
And , the inheritance has a problem that the module coupling between super-class and sub-class become higher.
In this page, I will explain the idea about the inheritance and attention of it.
For the time being, please read the quotation from eword (Sorry , this is a Japanese page ).
(Attention : The following is translated it into English form Japanese by me.)
In the object-oriented programming, this is that a new class appendding extensions and alterations is defined from a already defined class.
The based class is called "super-class" or "base-class" , and the new class is called "sub-class" or "derived-class".
The properties of the super-class are taken over to the sub-class , and the difference from the super-class is only defined in the sub-class.
When there are 2 or more super-classes , this case is called "multiple inheritance".
I describe the idea (bias?) about the inheritance 1.
I think that the inheritance is a idea to define the class taking over the attributes and operation ( fundamentally only access methods ).
But , I want you to think that the inheritance is really needed ( Can't you use the interface inheritance and composition ? ).
This is not related by using inheritance and not using it , but you should carefully design the data structures of the entities.
Because the data structures are related the maintainability of the program after that.
I think that the inheritance is by no means for do "incremental programming"
If you think the incremental programming , do you think by the POA (Process-Oriented Approach) ?
I want you to remember the weak points of the POA (Process-Oriented Approach. Actually, this is called Program-Oriented Approach too.)
The processes is more changeable than the datas.
If you define the sub-class based the class thought of the changeable processes, and when the super-class is changed , what do you do?
You must look at all sub-class again ( You must test all sub-class again ).
I think that the super-class is a class that is based from data.
If you want to realize the polymorphism , because the realization of the interface is able too , you should use it 2.
The polymorphism is idea that the behabior is changed by the object , but I'm anxious about the word of the "behabior".
Do you think in the POA?
The inheritance has some problem. I think that the interface realization and composition is better 3.
-----
Note.
1: Please not swallow. Because , these are extreme expressions. I might correct these sooner or later.
2: But , there are some cases that the inheritance must be used. For example , in the Java , if you need exception class , you must defined a class based java.lang.Exception.
But , I think that this case is right. Because , the java.lang.Exception class is the result that many research worker have studied.
3: The interface realization is lower module coupling than the inheritance.
When you understand the sub-class after , the necessary time become increase.
The definition of the sub-class is easy.
Really.
Because , you may only define the difference from the super-class.
But , when you understand after , you must understand the both...
This is often written by the books, the overinheritance is bad.
If the super-class is changed , the all sub-class is changed.
And , if the super-class is changed , the all sub-class is needed the test.
The module coupling between the super-class and sub-class is strong.
The module coupling seems more strong 1,2.
( But , I could not examine the kind of the the module coupling. I'm sorry. )
According to the programming language, The support situation is different.
In the VBA , the inheritance is not supported.
If the VBA version is 6 or more, the interface inheritance is supported. But if the Mac edition and Excel 97 , it is not supported too . Because the VBA version is 5.
The other , in the C++ language , multiple inheritance is supported. But , in Java language , it is not supported. Please pay attention.
The class may be used as the super-class , as not only the sub-class.
This is natural , when you override the operation in the sub-class , you must not change the meaning of the operation.
And , you may not change the precondition to severe.
If you need the detail , please read the "Liskov substitution principle - Wikipedia, the free encyclopedia".
I don't say "Don't use the inheritance". In the design pattern and in the Java API , the inheritance is used. In the Excel Lib too.
But , I want you to only pay attention.
------
Note.
1: The low coupling is good .
2: When the inheritance is used , the module coupling between super-class and sub-class becomes higher . This is written by the "Learning UML 2.0".
I only introduce the name of the principle about the inheritance. If you need the detail, please search.
Liskov substitution principle
If you need the detail, please search or read rinked HP.
Now I remembered that I think that the java.util.Properties class is against the Liskov substitution principle.
Why does the class inherit the java.util.Hashtable?
I think that it is wrong. ( If it has the object of the java.util.HashTable , I can understand. )
(In the page of the java.util.Properties class , the excuse is written.)
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.
