Re: pointers & OOP

[falis@ma.aonix.com (Ed Falis)]

On Fri, 14 May 1999 05:17:01 GMT, Matthew Heaney <matthew_heaney@acm.org> wrote:
> As I explained to Ed Falis (on Mar 19, 1998):
> 
> (start of excerpt)
> > Ed Falis <falis@ma.aonix.com> writes:
> > Third, I just plain dislike placing the field for linking onto the observers
> > list into the observer.  This is more an aesthetic issue than anything else,
> > but it makes implementation of the observer list just a little too visible
> > for my taste.
> 
> I take the attitude that when you have mutually dependent types,
> together in the same package, that the types must be treated as a unit.
> 
> The subject and observer types are highly cohesive parts of a larger
> abstraction ("publish subscribe"), and you can't study them
> independently of each other.
> (end of excerpt)
> 
> 
> <http://www.acm.org/archives/patterns.html>
> 
> Matt


Not sure exactly where "explainiing" came into it, "Magister", since my alternative also packaged the observer, observable and an event type together.  My 
disagreement was with the inclusion of the implementation field of the observable into the observer.

We have a philosophical difference on this.

In general, I tend to view abstractions as compositions of other abstractions.  In this particular case, you're right - it doesn't make sense to consider the roles of 
observer and observable independent of the publish-subscribe pattern.  But where does one draw the line?  When one composes an abstraction from other 
abstractions, do we then put all of it into a package?  Do we design it "top-down" so that the components of the larger abstraction can't be extracted and 
mixed at other levels of granularity, because they contain parts of the implementation of other roles?  Or do you figure one will always use multiple inheritance to 
mix in the pattern into application abstractions (that's rhetorical, because I don't think you buy it, though I often do).   The alternative seems to me to be custom 
crafting each "instantiation" of the pattern into a given design, which is what I've seen you do in many of your examples.  What happened to reuse, then?

Yes, I realize that a pattern is not a library or a design or software per se.  But that basic assumption doesn't contradict the desirability of good, flexible and 
_easily composable_ components that provide common implementations of patterns.

As time goes by, I've personally begun to question whether the flexibility of Ada's splitting of modularity and extension is worth the amount of plumbing one has 
to explicitly deal with when composing abstractions.  Indeed, there are some nice aspects to it, but it seems to add extra noise to the source code in the normal 
case, in order to accommodate the possibilities in less common contexts.  (Still not as noisy as the bulk of Java code one sees, though more noisy than Java's 
OO capabilities).  

Yeah, that's very subjective.  But frankly, I find myself having to work a lot harder to understand patterns I've seen "instantiated" in Ada than in some other 
languages.  And I'm no dope - I've been doing Ada OO for almost 5 years now, and using the language in general for a lot longer than that.  So, the approach 
mitigates against understandability for me - the "chunking" of independent concepts and abstractions seems too large.

Or maybe I'm just getting lazy in my old age, and don't like to have to work so hard to understand and use things (especially if I think there are simpler ways).

- Ed