Object-orientation is based on variance-encapsulation (see GoF), so to
practice object-orientation you must know:

A) What quality of a system is varying, and
B) How to encapsulate that quality.

Varying necessarily means, "Varying with time," so unless you're
planning to design a system that's moving into the past, then there is
some aspect of the future that you'll find yourself contending with.

People sometimes use the phrase, "Don't design for the future," as
though desiging-for-the-future carries a cost and
not-designing-for-the-future is free: this is an inaccuracy.

To practice variance-encapsulation you must of course practice
encapsulation; and to practice encapsulation you must identify your
system's natural fracture-lines and carve it up appropriately: those
carved pieces must then be encapsulated from one-another.

This is inevitable, whether you're designing for the here-and-now or
the ever-after; this is a cost even for
not-designing-for-the-future. (And make no mistake, there is a great
harvest of benefits to be reaped from this approach: increased
comprehensibility and maintainability to name but two.)

The question is: what informs these natural fracture-lines? What makes
encapsulating AB from C more, "Natural," than encapsulating A from BC?

The answer splits the discipline of obect-orientation in three, giving
rise to immediate, tactical, and strategic object-orientation.

If you're really lucky, your requirements will tell you, "We need a C,
but we also need a D and an E which should be swappable with C from
AB's point of view," and your iteration plan will say, "We need C, D,
and E delivered in the first iteration."

Then the solution is clear: you need to employ immediate
object-orientation: you are being told exactly what is varying and
what to encapsulate and when to deliver them altogether. Put C, D,
and E behind the same interface and have AB program to this
interface.

This is an XPer's (and most people's) delight. This is a sure sign
that your product is being driven by solid requirements. This project
will probably deliver a product that somebody (maybe the customer but
certainly Product Management).

If you're a little less lucky, your requirements will say, "We need a
C, but we also need a D and an E which should be swappable with C from
AB's point of view," and your iteration plan will say, "We need C, in
the first iteration, and D and E in the second and fifth iteration."

Then the solution is clear: you need tactical
object-orientation. You're being told exactly what is varying and what
to encapsulate and that they'll be delivered at different times.

Only the shortest of the short-sightest would look at the requirements
for the first iteration in isolation, and decide not to encapsulate C
from AB. So here we are designing for the future, but there are
degrees of future, and this future seems pretty certain.

Of course no future is completely certain, and in the second
iteration, the requirements may change, and the D and E parts may be
dropped, meaning that the fracture-line you've chosen to cut between
AB and C could have been a waste of time; but even if those
requirements hadn't been dropped, you might still have chosen to cut a
fracture-line somewhere in the mass of ABC, just for
comprehensibility/delivery/maintainability - and those benefits are
still accrued from the AB/C split.

Finally, you may have no requirements beyond the end of your project,
and thus don't know what might vary, and so don't know what to
encapsulate. But there are always hints to be found in the nature of
your product. (And this is where a product road-map is essential to
object-orientationists.)

If you're designing an operating system, you probably won't hard-code
it to a particular file system. You have no requirements on your desk
taht say, "We'll have a new file system in three releases' time," but
it's possible, so you may chose to encapsulate the file system from
the kernel.

Similarly, you may be designing a car's engine-control system, and
decide that, in future, an electric engine might come along after the
current diesel engine, and so encapsulate those parts common to
both. In the end, of course, no electric engine may come along, and
that encapsulation work might be completely wasted.

This is strategic engineering, and it is the most dangerous
(uncertain) of the three. XPers seldom invest much effort in this; and
I think they may be right.

I doubt that the best approach to product-development is either a
rabid fear of the future or an all-comsuming addiction to it. The best
(that is, most cost-effective) solutions tends to snake somewhere
between the two.

Gotta love engineering ...

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Actually I think "Design for Extension" can work very well with XP. The
difference from the normal approach is, that whenever you need to
extend a class, you cannot just make a subclass and override a method;
you need to refactor the base class and add an extension hook somewhere
first.

I think this might be a very good way of developing software. These are
the advantages/dissadvantages I see with this approach:

+ No beeing able to forgett to call super() in a subclass
+ Whenever behaviour of the base class is modified, it is done at a
place where it is designed to be extended.

- You have to be able to access and modify all the code you have to be
able to add hooks which can be very problematic with libraries.

Actually I think "Design for Extension" can work very well with XP. The
difference from the normal approach is, that whenever you need to
extend a class, you cannot just make a subclass and override a method;
you need to refactor the base class and add an extension hook somewhere
first.

I think this might be a very good way of developing software. These are
the advantages/dissadvantages I see with this approach:

+ No beeing able to forgett to call super() in a subclass
+ Whenever behaviour of the base class is modified, it is done at a
place where it is designed to be extended.

- You have to be able to access and modify all the code you have to be
able to add hooks which can be very problematic with libraries.