Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Matthew Heaney <matthew_heaney@acm.org>]

jerry@jvdsys.stuyts.nl (Jerry van Dijk) writes:

> The implementation of the idea seems to be decoupling through
> dispatching and access types. Looking at your example, I see:
> 
> :   type Root_Hamburger_Type (<>) is abstract tagged limited private;
> :   type Hamburger_Access is access all Root_Hamburger_Type'Class;
> :   function New_Hamburger return Hamburger_Access;
> :   function New_Hamburger return Hamburger_Access;
> :   Hamburger : constant Hamburger_Access := Factory.New_Hamburger;
> 
> With other words, pointers seem to be the essential tool for using this
> design method. 

Yes, but smart pointers and access params mitigate this issue.

> Although the thinking behind the pattern idea is powerful by its rigid
> application, whenever I try to apply it, I end up with programs that
> seem to become impregnable through the heavy use of indirection,
> overloading and dispatching. 

If you use the idioms I list below, then the indirection goes away.  And
the whole point of dispatching is to hide which operation is getting
called.

> Gone is the "clear and elegant" (for lack of better wording) ADT based
> structure I like so much in Ada.

Perhaps the example is bad.  As the last paragraph of my article notes
(paraphrased from the GoF book):

As an example of this idea, you could use a factory to implement a
platform-neutral windowing API.  When you port your application to
another operating system, all you need to do is compile against a
different factory.  Your code is otherwise unchanged.


> Now, it could be that this is indeed true, but I rather suspect that I
> made a wrong turn somewhere. Anyone who has been there, and solved this
> problem ? 

Read my recent articles in the ACM patterns archive (see especially Abstract
Factory Revisited), where I address the access-via-indirection issue.

<http://www.acm.org/archives/patterns.html>

When implementing a hierarchy of tagged types, I usually do the
following things (from the cited article):

o implement the root type as indefinite and limited

o have each derived type in the class export a constructor that returns
a (smart) pointer to that specific type

o have the primitive operations of the type take access parameters, so
that there's no need to explicitly dereference the return value of the
constructor (an access object)

o declare a primitive operation that's private (not visible to clients
outside of the package hierarchy), to deallocate instances of the type


If you just declare instances statically, say in a package body, then
access via a pointer may not be necessary.  

But it's often the case that you have a collection of instances of the
class-wide type.  Since a class-wide type is indefinite, you have no
other choice than to put the items on the heap.

That's why smart pointers and access parameters are helpful.  Access
params give you the same syntax as you had before with classic ADTs, and
smart pointers take care of memory management details.