Re: pointers & OOP

[Matthew Heaney <matthew_heaney@acm.org>]

John Robinson <john@jr-and-assoc.demon.co.uk> writes:

>>Very often putting multiple types into a single package solves in a
>>neat and clean way nasty problems that simply don't have neat solutions
>>in other languages.
> 
> Such as?  

Here's one reason: giving types mutual access to each other's
representation.  It's like a "friend" in C++.

Sometimes, two types are just highly cohesive, and you never use one
with also using the other.  A classic example is a data structure and
its (active) iterator.


> The use (in general) of one "major" type per package goes back to my
> earliest days with Ada 83, and is of course inherent in Booch's
> original "Software Engineering with Ada" text which was so influential
> in the adoption of ADT-based programming in the Ada world.

But if Booch had provided active iterators, then he would have declared
them together in the same package.


> This approach, which I have (so far) successfully carried over into
> Object Oriented Ada 95 code, brings a number of benefits
> (e.g. straightforward traceability between analysis and code, very
> clear separation of concerns etc).

No one is arguing that you put just any types together in the same
package.  We all agree that that is a bad thing (because it causes
unnecessary compilation dependencies).


> However, I am open to other approaches, if the benefits are clear.

It's called a "package" for a reason -- because it holds in one place
all the entities associated with an abstraction.

Be careful not to confuse a module with a type.  In Ada, an abstraction
is provided by a package (or hierarchy of packages).  That one or more
types are used to implement the abstraction, well, that's just a feature
of the implementation.  It's the package (really, objects) that's the
important thing.

That's why when you trace analysis or design artifacts to code, you
should really be tracing them to packages with state, not types.  It's
objects that are important -- types (even ADTs) are mere implementation
details.

You can (and should) implement abstractions using a package only,
without using any abstract data types.  This is how you implement
well-known objects, a static abstraction whose cardinality is known up
front.  A singleton is the limiting case of a well-known object whose
cardinality is one.

The package Ada.Text_IO is a good example of an abstraction that
contains multiple types and static state.  The abstraction is "text
i/o", not just "file type".

Package Text_IO contains these types:

  File_Type
  Count
  Positive_Count
  File_Mode

and at least three local variables:

  Standard_Input
  Standard_Output
  Standard_Error

See my articles about singletons/well-known objects in the Feb 97 and
Jun 98 archives.


> >You are tieing BOTH hands behind your back if you adopt this completely
> >unnecessary and damaging restriction.
> 
> I would be very interested in seeing a specific example of why this is
> damaging.  Perhaps a specific reference to the patterns archive cited
> by Matthew?


Study the article Iterator and Factory Methods Combined, in the Nov 98
ACM patterns archive.  In that example a stack has a factory method that
returns an iterator.

See also the examples and discussions of the Observer pattern, in the
March 99 archive.  For example, here's the spec:

  package Subjects_And_Observers is

     type Root_Subject_Type is
       abstract tagged limited private;

     procedure Notify 
       (Subject : in out Root_Subject_Type'Class);


     type Root_Observer_Type 
          (Subject : access Root_Subject_Type'Class) is
       abstract tagged limited private;

     procedure Update 
       (Observer : access Root_Observer_Type) is abstract;

    ...

  end Subjects_And_Observers;



One abstraction, one package, two types.  

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