Content deleted Content added
m →Subclasses and superclasses: clarify previous edit |
m →Subclasses and superclasses: removed my prev edit, the issue is more complex and the description would as such be wrong. |
||
Line 41:
Some [[programming language|programming languages]] (for example [[C Plus Plus|C++]]) allow [[multiple inheritance]] -- they allow a child class to have more than one parent class. This technique has been criticized by some for its unnecessary complexity and being difficult to implement efficiently, though some projects have certainly benefited from its use. [[Java programming language|Java]], for example has no multiple inheritance, its designers feeling that this would be more trouble than it was worth.
Sub- and superclasses are considered to exist within a [[hierarchy (object-oriented programming)|hierarchy]] defined by the inheritance relationship. If multiple inheritance is allowed, this hierarchy is a [[directed acyclic graph]] (or DAG for short), otherwise it is a [[tree (graph theory)|tree]]. The hierarchy has classes as nodes and inheritance relationships as links. The levels of this hierarchy are called [[layer]]s or [[level of abstraction|levels of abstraction]]. Classes in the same level are more likely to be [[association (object-oriented_programming)|associated]] than classes in different levels.
There are two slightly different points of view as to whether subclasses of the same class are required to be disjoint. Sometimes, subclasses of a particular class are considered to be completely disjoint. That is, every instance of a class has exactly one ''most-derived class'', which is a subclass of every class that the instance has. This view does not allow dynamic change of object's class, as objects are assumed to be created with a fixed most-derived class. The basis for not allowing changes to object's class is that the class is a compile-time type, which does not usually change at runtime, and polymorphism is utilised for any dynamic change to the object's behaviour, so this ability is not necessary. And design that does not need to perform changes to object's type will be more robust and easy-to-use from the point of view of the users of the class.
From another point of view, subclasses are not required to be disjoint. Then there is no concept of a most-derived class, and all types in the inheritance hierarchy that are types of the instance are considered to be equally types of the instance. This view is based on a dynamic classification of objects, such that an object may change its class at runtime. Then object's class is considered to be its ''current'' structure, but changes to it are allowed. The basis for allowing object's class to change is performance. It's more efficient to allow changes to object's type, since references to the existing instances do not need to be replaced with references to new instances when the class of the object changes. However, this ability is not readily available in all programming languages.
nvo
==Reasons for implementing classes==
| |||