Re: Program to an Interface not an implemetation
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Fri, 23 Sep 2005 16:07:47 GMT
Responding to Will...
I am looking at the Gang of Four Design Patterns and wondering about the advice 'Program to an Interface, not an implementation'. If, for example, I have many similar classes all needing, say tax and list price then I should use an interface and factories so that I decouple and am cohesive. I then pass the Inteface object to one method which polymorphically gets the right implementation from my concrete classes.
Note that almost all of the GoF patterns are addressing a single class of problems where a simple association between client and service cannot capture complex dynamics in context that can lead to substitution of implementations _for the same behavior_. IOW, for the sorts of problems that the GoF patterns address, the fact that a common <abstract> behavior exists is a given. So...
But in my experience, most classes are not similar enough to do this. Rarely a couple of classes maybe. Even, say 2 types of vehicle may not both have a list price and tax (one exported for example) so is an interface suitable across many of these absractions? Most real world abstracted classes are riddled with their own particular foibles which makes finding commonality a nightmare.
Delegation and inclusion polymorphism are just tools for solving problems. If the tool doesn't fit, then don't use it.
However, I think there is a more fundamental issue here. The distinguishing thing about the OO paradigm is the militant use of abstraction. We can use abstraction to find commonality in almost anything. It is that ability that make inclusion polymorphism a powerful tool. For example:
1 attacks 1
[Predator] ------------------- [Prey]
A
|
+--------------+----------------+
| | |
[Gazelle] [Pheasant] [Brontosaurus]
+ run() + takeFlight() + stomp()When a Predator attacks a Prey each type of Prey may have a unique response to that attack and, as in the example, those responses can be very different. However, through the magic of abstraction we can view the response of [Prey] at a higher level of abstraction:
1 attacks 1
[Predator] ------------------- [Prey]
+ RespondToAttack()
A
|
+--------------+----------------+
| | |
[Gazelle] [Pheasant] [Brontosaurus]Instead of thinking in terms of specific responses we step back and think in more general terms about what is actually going on. Now we can accommodate all three responses through a single interface method. The substitution of actual response in the subclass implementation is transparent to the Predator.
Given we are doing things in an OO manner, the responses will likely subsequently collaborate with the Predator during the chase. But that can be abstracted as well so that the collaboration is independent of the specific response. For example, the [Prey] can simply update [Predator] with position data so that [Predator] can react in its own way.
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- Program to an Interface not an implemetation
- From: Will
- Program to an Interface not an implemetation
- Prev by Date: Tool for reverse engineering C++ code
- Next by Date: Re: Modeling
- Previous by thread: Re: Program to an Interface not an implemetation
- Next by thread: Re: Program to an Interface not an implemetation
- Index(es):
Relevant Pages
|
