
- Forum
- Testing
- Software Patterns
- Problems with the composition over inheritance paradigm
Problems with the composition over inheritance paradigm
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 ...
-
02-14-2004, 02:35 PM #1Malte Persike Guest
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
-
02-15-2004, 10:29 AM #2EventHelix.com Guest
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
-
02-15-2004, 02:26 PM #3Malte Persike Guest
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
-
Sponsored Ads
«
Financial Patterns or Frameworks
|
Solving Lazy Initialization and double checked locking problem
»

Reply With Quote





