From: Hal Fulton <hal9000@...>
Date: 2003-09-03T23:41:58+09:00
Subject: Re: holub and OOP flavors

Joe Cheng wrote:

> Just want to surface this link to everyone involved in the (rather large)
> subthread of OOP flavors:
> 
> http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
> 
> james_b posted it as a footnote but I thought people might easily miss it.

I will add it to my list of things to read. Near the top of the
list, as the list grows faster than it shrinks.

[snip]

> The point is, I *don't* think the following should be the primary factors
> that decide whether x.foo(y) or y.fooTo(x) is best:
> * x.foo(y) is more natural because it's x that does the fooing.
> * In the Real World, you don't tell a y to fooTo x, you just foo the y with
> x.
> * It just feels wrong, I don't know why.
> 
> Instead I think the thought process should sound more like:
> * x is more likely to change in the future, so I would like to keep its
> implementation particularly opaque and its public interface particularly
> compact.  Therefore I will choose x.foo(y).
> * Many classes are likely to have an "is-a" relationship to y, and I would
> like future developers to be able to provide their own implementations of
> fooTo, so I will choose y.fooTo(x).
> 
> The latter two questions may not be as intuitive as the former, but I
> believe they are much more relevant if the goal of a design is to
> effectively manage complexity.

OK, I find this logic compelling.

This points up the fact that there is much more to maintainability
than just readability. (Although I'm a big fan of readability in its
own right.)

I guess in a situation like this, I'd try as usual to get the best of
both worlds. I'd probably have a set of front-end objects that behaved
intuitively, interfacing to a set of backend objects that were
implemented in a more maintainable way. That would introduce a kind of
extra layer of abstraction.

But I'm being vague here because I haven't thought this through. Let me
just say that I like *both* sets of constraints. And perhaps the first
set should not be of primary importance, but I think they should run
a very close second. I wouldn't write "weird OO" unless I really needed
to, just as I wouldn't drop into C unless I really needed to.

This has been thought-provoking. If I am not careful, I may learn
something.

Hal