This is a discussion on Problems with the composition over inheritance paradigm within the Software Patterns forums, part of the Testing category; Hello everybody, the GoF book states on multiple occasions that object composition should be preferred over inheritance whenever possible. I ...
|
|||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Problems with the composition over inheritance paradigm
Hello everybody,
the GoF book states on multiple occasions that object composition should be preferred over inheritance whenever possible. I have come to highly value this suggestion because it drastically reduces the complexity of inheritance trees and all the accompanying maintainability issues. But there are cases where I have problems finding a reasonable implementation for these composite structures. Consider some kind of TObjectList that shall be equipped with a MaxEntries property to limit its maximum capacity and other additional properties as well, making it a, say, TConstrainedObjectList. As I am devoted to use object composition I would design a class that has the TObjectList as a property together with the other properties. But how do I effectively restrict the capacity of the TObjectList? What I have come up with so far is two possible solutions: a) The TConstrainedObjectList mirrors the whole interface of the TObjectList mapping methods that do not change the item number directly to the TObjectList and adding a constraining logic to the other methods like Add() or Insert(). b) Making the TConstrainedObjectList an observer of the TObjectList. Whenever an item is added the TObjectList it notifies the TConstrainedObjectList which then checks if the the TObjectList exceeded its limits. I chose b) because it is faster to implement especially with complex classes although a) feels somewhat cleaner. Because this is a recurring problem I wonder if you have found a more elegant solution. Kind regards, Malte -- The above e-mail address is not valid. To contact me, please use my real e-mail address: malte AT t DASH online DOT de |
|
|||
|
Re: Problems with the composition over inheritance paradigm
"Composition over Inheritance Paradigm" is a good strategy but if the
relationship is best modeled by "is a" then so be it. Use inheritance. In your example inheritance seems to be more suitable. Sandeep -- http://www.EventHelix.com/EventStudio EventStudio 2.0 - System Architecture Design CASE Tool |
|
|||
|
Re: Problems with the composition over inheritance paradigm
On 15 Feb 2004 07:29:43 -0800, eventhelix@hotmail.com (EventHelix.com)
wrote: >"Composition over Inheritance Paradigm" is a good strategy but if the >relationship is best modeled by "is a" then so be it. Use inheritance. > >In your example inheritance seems to be more suitable. You are right, thanks. Sometimes it's just a little complicated to find the "best model" suiting the target domain. Malte. -- The above e-mail address is not valid. To contact me, please use my real e-mail address: malte AT t DASH online DOT de |