Re: Classes: when and where? (long) (was: looking for a nail)

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

[snip]
> but until then I feel the jury is out.  (IMHO, given the contorted nature of
> many OO-based attempts at abstraction, one might feel the jury could have
> given a preliminary verdict some time ago ;-) )
> On the question of project failures: I would certainly blame the failure
> and/or slow-progress of several projects I've seen on the mis-application of
> OO design techniques, in particular on the over use of inheritance and
> subtyping as an abstraction technique, and the over use of abstraction in
[snip]

If things do not work so fine with OO, it would be a bit too early
to blame this paradigm for failure. I think the problem is a totally
different one: the design approach.

Thinking back about courses in software engineering (with OO), the
design approach taught was mostly "from top down". In my first projects
I almost often failed completely to implement the design I developed
without fundamentally changing it.

A severe example:
it took me quite some weeks to develope a class system for a specific
project. When it was implemented as designed, I noticed that I had
overlooked many necessary properties to make it work as it should. So I
started to change it. It became worse and worse until I finally decided:
let's kill this beast. I tore out all algorithms / functions, etc.,
which I would need anyway, put them together into small components that,
again, would be needed anyway. Then I did the same with these components
and when I was ready, it more or less worked "out of the box" - within
less than two days.

This "lesson" showed me that the top-down approach is not such a good
method - at least for my style of programming. All that counts in the
long run is: when does the program/prototype work. Instead of investing a
lot of effort into designing "class hierarchies" or "interfaces", I now
begin immediately with implementing small components, of which I know
that they will have to be in the final system anyway - no matter, how
"important" they seem from a "higher-order" point of view. When I have
all these small components, I try to build with them the next "layer of
abstraction" that will bring me closer to the final result - and so forth.

This doesn't seem to be so problematic with modules: I think that modules
enforce a coding style that focuses on "the component" - not so much on
the "system view". If the module works, which is much easier to achieve
because of the smaller size/complexity, it is truly reusable. But
if I fail in the design phase of an OO-system to correctly see all
dependencies between the classes/objects, I will be in deep trouble,
because then I have to manage the whole system complexity at once.


So if you say, that there was an overuse of abstraction techiques,
it might well be due to the wrong "direction" of development: they
tried to begin with the abstractions instead of with the components.
It is probably not a matter of "how abstract" something is, but how this
abstraction came into existence...

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl