Advertisement

Interface Design | Contents | Previous | Next

Stack extends Vector is a great example of where is-a wasn't really satisfied, and composition would have been much more flexible. Also, the Vector methods didn't really belong in Stack. When the retrofitted Vector to implement List, a whole bunch of other methods got added to the Stack interface.

A big part of the adapter pattern's significance is that it shows that objects involved in a composition relationship have interfaces that are independent of each other.

Ripple effect from changing a back-end class stops (or can stop) at the front-end class

---

Composition vs. Inheritance

Inheritance Yields (Slightly) Better Performance:

• Composition's method forwarding/delegation will often be slower than inheritance's dynamic binding
• Composition results in more objects getting instantiated, which can incur a performance cost at allocation, <init>(), and GC time

Composition Yields Better Flexibility:

• Interfaces of classes involved in a composition relationship need not be compatible, so it's easier to change the interfaces
• Composition allows you to delay creation of back-end objects until (and unless) you need them
• Composition allows you to change back-end objects throughout the lifetime of the front-end object
• Composition allows front-end objects to share the same back-end objects

But:

• Composition's method forwarding/delegation results in more code that has to be written, debugged, and maintained.
• Easier to add new subclasses than new front-end classes, unless you use composition with interfaces

Describe adding method to superclass that has same name but different semantics as subclass. Also the problem of just inheriting an added method signature that you don't want in the subclass.

Class extension (full-blown inheritance -- interface and implementation) is like strapping on a backpack in which your instances carry around not only their own instance variables and everything they refer to in a graph of objects, but also those of all their superclasses. If you don't own the superclass, owner can change superclss by adding lots of heavy instance data that gets added to your backpack and you don't have a choice but carry it around everywhere. The owner can also add a method to the superclass interface that you don't like in your subclass, but suddently its a part of your interface whether you like it there or not (or, what's the ultimate problem has, the same signature but incompatible semantics as an existing method in your subclass). If the superclass owner adds lots of heavy instance data to the superclass, that owner basically has added all that weight to your subclass instance's backpack. Your subclass instances have no choice but carry that around everywhere they go. (In a composition relationship you could change the back-end object, delay initilization until needed, share same backend amont multiple front-ends, etc...)

Could show the decorator example from chapter 4 in UML form and mention the intent thing?