Program to an interface not an implementation?

[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.

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.
In fact it can make the app very difficult
to follow for the next programmer. They have to
grasp subtleties in the construction that make
quick updates nearly impossible. It can be a
tortuous, rational spaghetti that is difficult
to see what calls what and why. The app does
'secret' things that are obvious when you know
what but difficult to reverse engineer. I spend
a lot of time unravelling code that borders on
being pompous. (I know a person can be pompous
but can code be pompous too?)

If we want ultimate cohesion and decoupling, then
why don't we make a separate a class of every
property and method and use use 100s of interfaces?
What spaghetti trhat would be!

Does any person know what the present thinking
is since the gang of 4? Have we moved on and
upwards. What is the latest
bees knees in OO thinking. Or are we back to
every application should be considered on its
own merits.

 

[Thomas G. Marshall]

Will coughed up:

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.

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.
In fact it can make the app very difficult
to follow for the next programmer. They have to
grasp subtleties in the construction that make
quick updates nearly impossible. It can be a
tortuous, rational spaghetti that is difficult
to see what calls what and why. The app does
'secret' things that are obvious when you know
what but difficult to reverse engineer. I spend
a lot of time unravelling code that borders on
being pompous. (I know a person can be pompous
but can code be pompous too?)

If we want ultimate cohesion and decoupling, then
why don't we make a separate a class of every
property and method and use use 100s of interfaces?
What spaghetti trhat would be!

Does any person know what the present thinking
is since the gang of 4? Have we moved on and
upwards. What is the latest
bees knees in OO thinking. Or are we back to
every application should be considered on its
own merits.

Repost this immediately in comp.object. You'll get a *lot* of good answers
there!!!!

 

[iamfractal]

Will skrev:

But in my experience, most classes are
not similar enough to do this.

No great insight to offer, but I will say that my experience matches
yours; but I do not seek such similarity between most classs.

If we want ultimate cohesion and decoupling, then
why don't we make a separate a class of every
property and method and use use 100s of interfaces?
What spaghetti trhat would be!

Engineering is compromise. It's rarely cost-efficient to take one
dimension of engineering and optimise it at the expense of all others.
The flexibility OO offers is not free: comprehensibility suffers as a
consequence.

Ultimate cohesion is not a great design goal: if it were, software
engineering would be rather easy. A good design goal is a
cost-efficient optimisation of flexibility, performance,
comprehensibility, and quality, all while delivering required
functionality on-time. No easy trick.

Do note, however, that Design Patterns also harps on about variance
encapsulation: a strong reason for putting an implementation behind an
interface is that you expect the implementation to change or you expect
to add new implementations, all without changing the interface.

If your two types of vehicle have a tax and a list price, then you
should put both behind the same interface if you expect to encounter
other types of tax and list prices that can be managed with the same
interface. If you can't, then don't bother with the expense of the
abstractions.

Or are we back to
every application should be considered on its
own merits.

Perhaps not every application, but every project should be considered
on its merits, as perhaps has always been the case. For some customers
time-to-market is everything, so quality will take a nose dive;
safety-critical software no doubt takes longer to test so productivity
will take a nose dive. Horses for courses.


..ed

 

[Will]

TY Thomas, I have reposted on the group: comp.object.