Collection interfaces

[Alex Martelli]

"Topmind" <topmind at technologist.com> wrote in message
news:MPG.1506265ebf6d934d9896be at news.earthlink.net...
> > On Wed, 28 Feb 2001 02:11:10 GMT, Topmind <topmind at technologist.com>
> wrote:
> > >> And when they do, one refactors appropriately
> > >
> > >Refactor is a great PHB-directed euphemism for
> > >code rework. Call it whatever you want, but it is
> > >still unnecessary work.
> >
> > But given that requirements change and lacking a reliable Delphic
> > Oracle, it's impossible to divine the correct solution at the
> > beginning, so the code rework is unavoidable and necessary.
> >
> > [snip]
>
> The point is to *minimize* the changes needed. If the
> changes don't match a method's boundaries, you have MORE
> work than what you usually have in task-oriented
> procedural/relational programming.

Not with a good (minimal) process, helpful tools, and, most
particularly, the right mindset (which is both cause and
consequence of the good/minimal process).  Before you knock
it, TRY it -- pick a pilot project of suitable size, a team
ditto, and have a go at it with eXtreme Programming -- code
test-first, *refactor mercilessly*, and *do the simplest thing
that can possibly work*, being the three keys here... and do
note that they work together, *sinergically*.  (No doubt you
will consider this "a euphemism", too, but, as usual, I'm just
striving to use words precisely; I don't particularly care if
others use should-be-precise words, such as 'sinergy' or
'refactor', as euphemistic cover-up for lack of substance).


> For more details, please see:
>
> http://www.geocities.com/tablizer/boundary.htm

This seems to show what blind alleys classical approaches can
lead one to -- ```Reorganization can be risky. Many managers do
not want programs altered except to add or fix features. If an
significant error occurs due to reorganization, then heads roll.
I have been told many times, "If it ain't broke, please don't
fix it."''' being the key quote from that paper.

>From that unproductive mindset, among many other ills, comes
the "boundary fixation" with which the rest of the article
appears to be obsessed.  (But the ills are many indeed; the
"lava flow" anti-pattern, for example, is likely to be quite
pervasive in a development shops to which this article could
apply).

But the right unit of encapsulation is NOT the method, nor
the object, nor the class; it's a *component*, a small to
middling set of classes/objects/methods (and, in languages
which allow other organizing structures, functions, modules,
etc), which are developed and tested and released _and, thus,
reused_ *together*.  Component boundaries are indeed of very
high relevance.  Boundaries _within_ a components are not.

[Restructuring in a way that alters component relationships
is one thing -- it is, indeed, *re-architecting* a whole
software *system*; only *system-level* (aka 'integration')
tests will catch re-architecting problems, a good part of
test-suites that unit-test specific components or small
groups thereof will have to be scrapped, etc, etc.]

Restructuring code, design, and even architecture *behind*
the abstract interfaces which relate components is (should
be!) a low-risk, high-frequence activity.  Test suites MUST
be good enough to provide very high ensurance that a group
of components is still working to specs -- there is just no
working around THAT; if your test suites are so deficient
at the component and unit level, "not fixing what isn't
broken" is not an option, as you CAN'T KNOW what IS and what
isn't broken!


*Analogy warning, proceed at your own risk*...!-)

```Crossing a street can be risky. Many parents do not want
streets crossed except to reach a school or doctor. If an
significant accident occurs due to crossing, then heads roll.
I have been told many times, "If it ain't truly indispensable
to be on the other side, please don't cross the street"'''.

Adopting the 'software that happens to appear to work when
not thoroughly tested is sacred and must not be touched' idea
is parallel to keeping a kid always on his/her side of the
street (except perhaps for emergencies such as schools and
doctors:-).  Not exactly conducive to optimal development
(be it of social skill and a healthy life, OR good software).

Providing safer approaches to street-crossing (underpasses
and overpasses on high-traffic thoroughfares, lots more
dead-end streets with speed bumps in residential areas,
etc) is a far preferable attitude to trying to build, on
the one block a kid is going to be confined to, all he or
she could possibly ever need -- ice-cream stand, burger
joint, public library, and so on -- which seems to me to
be what you're advocating in the software (specifically,
collection-interfaces) realm.


Alex