Discussion
The safety is not always compatible with the notion of reusability.
- The conflict between inheritance and safety is a problem for OOPL too.
- Safety can not always be guaranteed.
Inheritance is a natural consequence of the IsA relationships.
However, inheritance sometimes renders inadequate modeling.
Consider two classes rectangle and square, with squares being specializations of rectangles:
rectangle: [
center: point,
sidelength: INTEGER,
secondsidelength: INTEGER ]
|
|
|
square: [
center: point,
sidelength: INTEGER ]
|
|
square: [ center: point, sidelength: INTEGER ]
rectangle IsA square: [ secondsidelength: INTEGER ]
|
Multiple inheritance can be simulated by single inheritance using
delegation, which can be useful in situations where the desired effect of reuse could not be achieved by inheritance in an intuitive way.
For example, extend the manager definition to include the shares of a manager:
manager IsA employee: [
staff: { employee } ]
|
|
⇒
|
manager IsA employee: [
asshareholder: shareholder,
staff: { employee },
myshares: INTEGER ]
PRIVATE: asshareholder
|
|
Whenever we create a
manager object, we now have to create a
shareholder object as well.
Any call to
myshares will delegate this call to the corresponding
asshareholder object by executing the path expression
asshareholder.shares, for example.
“The invariable mark of wisdom is to see the miraculous in the common.”
― Emerson
|