Suppose I have such requirement:
The objects in the system all derive from a base class named IObject, and it may have objects with color, objects with transformations, and both.
Now there are 2 approach to design the class hierarchy.
The first one is:
just let concrete class derived from
IObject, and also select “capability”
interfaces as its base class to
indicate it support such behavior,
like interface: IHasColor,
IHasTransformation
The second one is:
Organize the base classes, and let
concrete classes derived from one of
them: IObject, IColorObject,
ITransfromationObject ,
IColorAndTransformationObject
I prefer the first one (Does it have a formal name? ) as it is more flexible, and as you can see the second one may have class combination explosion problem when there are many attributes like color, transformation…
I would like to know your ideas and suggestions.
Thanks.
Classes abstract the real concept of types of objects.
Interfaces abstract the real concept of behaviors or abilities for an object.
So the questions becomes, is the “color” a property of the object or is it a capability of the object?
When you design a hierarchy you are constraining the world into a narrower space. If you take the color as a property of the object then you will have two kind of objects, the ones that have colors and the ones that do not. Does that fit your “world”?
If you model it as a capability (Interface) then you’ll have objects that are able to provide, lets say cast, colors to the world.
For the transformation the same logic applies. You can either split the world into two kind of objects, the ones who can transform and the ones who can not, or you can view it as a capability, an object may have the ability to transform itself into another thing.
For me, from that point of view, what would make sense would be: