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.