ANNOUNCE: Abstract Factory posted to ACM patterns archive

ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Matthew Heaney]

I have prepared a short article on how to implement the Abstract Factory
pattern in Ada95, and posted it to the ACM patterns archive.  The
introduction of the article appears below.

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

I've been slowly converting the C++ examples in the book Design Patterns
to Ada95.  In each article I discuss the pattern, explain how to
implement it in Ada, and explore various idioms and language features.
A complete, working example with all the code is included.

You can subscribe to the patterns list by sending a message with the
body:

subscribe patterns <your full name>

to the ACM mailing-list server.

<mailto:listserv@acm.org>

Matt


Abstract Factories Revisited

In this article I discuss an alternate version of the abstract factory,
implemented using static polymorphism.

The example also uses the smart pointer pattern to take care of memory
management, and declares a singleton instance of an abstract data type.


Discussion

Way back when I showed how to implement the abstract factory pattern in
Ada95, using an example that more or less followed the one in the GoF
book.

In that version, the abstract factory is implemented as a class.  You
decide which kind of factory you want, and declare an instance of that
specific type, which gets elaborated during program initialization.

Ed Colbert gave me the idea that the abstract factory could be
implemented as a library-level renaming of another package.  What a
great idea!  Static polymorphism without it being a generic.

In this alternate version of the abstract factory pattern, I got rid of
the factory types, and just implemented factories as packages with an
identical interface.  The actual factory that is used as _the_ factory
is chosen by way of a library-level renaming.

If you recall, the example from the book was a maze game, in which you
enter rooms, doors, and walls.  Another version of the game features
"enchanted" maze items, and you select which version of the game you
want by choosing a different factory.

What we do here is first declare a family of maze item types, then
create a (singleton) maze object, using the factory to select the maze
items.  You get a maze whose behavior changes based on which factory you
use.

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[dennison]

In article <m3hfs14zhn.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> I have prepared a short article on how to implement the Abstract Factory
> pattern in Ada95, and posted it to the ACM patterns archive.  The
> introduction of the article appears below.

For those of us not up on the latest hip OO lingo, could someone please
explain what a "factory" is? FOLDOC didn't know, and the ACM website just
assumed I know.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Peter Milliken]

Not really "hip OO lingo", it's just the name of one of the patterns written
up in the "Gang of Four" (GoF) book on design patterns (copyright in my
edition is 1995). All of Matthew's postings have been dealing with
implementation of these design patterns into Ada95 (the book contains examples
in C++).

Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John
Vlissides.

"Factory Method
Intent:
Define an interface for creating an object, but let all subclasses decide
which class to instantiate. Factory Method lets a class defer instantiation to
subclasses."

Hope this helps :-)

Peter

dennison@telepath.com wrote:

> In article <m3hfs14zhn.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> > I have prepared a short article on how to implement the Abstract Factory
> > pattern in Ada95, and posted it to the ACM patterns archive.  The
> > introduction of the article appears below.
>
> For those of us not up on the latest hip OO lingo, could someone please
> explain what a "factory" is? FOLDOC didn't know, and the ACM website just
> assumed I know.
>
> T.E.D.
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Matthew Heaney]

dennison@telepath.com writes:

> For those of us not up on the latest hip OO lingo, could someone please
> explain what a "factory" is? FOLDOC didn't know, and the ACM website just
> assumed I know.

"Factory" just has its common meaning: an abstraction that you use to
create other abstractions.  This is why it falls under the rubric of
"creational patterns."  Different factories create different items.

Consider "factories that make hamburgers."  MacDonald's is a factory
that creates one kind of hamburger.  Burger Kind is different factory
that creates another kind of hamburger.  Carl's Jr. is yet another
different factory that creates yet another kind of burger.

Now think of code:

package Hamburgers is

  type Root_Hamburger_Type (<>) is abstract tagged limited private;

  type Hamburger_Access is access all Root_Hamburger_Type'Class;

  ...
end Hamburgers;


package MacDonalds is

  function New_Hamburger return Hamburger_Access;

end MacDonalds;


package Burger_King is

  function New_Hamburger return Hamburger_Access;

end Burger_King;


Now, if we do this:

package Hamburger_Factory renames Burger_King;

and then a client does this:

with Hamburger_Factory;
procedure Eat is

  Hamburger : constant Hamburger_Access := 
    Factory.New_Hamburger;

begin
...


A client who wants to eat a hamburger doesn't have to care which
restaurant it came from, because he's only referring to the factory "in
the abstract" (hence the name), by with'ing Hamburger_Factory.

Library-level package renaming is a feature Ada provides for
implementing static abstractions.

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Jerry van Dijk]

Matthew Heaney (matthew_heaney@acm.org) wrote:

: "Factory" just has its common meaning: an abstraction that you use to
: create other abstractions.  This is why it falls under the rubric of
: "creational patterns."  Different factories create different items.

As I recall from the GoF book, my impression (also stated somewhere,
I believe) was that one of the essentials was using construction instead
of inheritance as the main design principle. 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. 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. Gone is the "clear and elegant" (for lack of
better wording) ADT based structure I like so much in Ada. 

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 ? 

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Matthew Heaney]

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.

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[fraser]

paene lacrimavi postquam jerry@jvdsys.stuyts.nl (Jerry van Dijk) scribavit:

>With other words, pointers seem to be the essential tool for using this
>design method. 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. Gone is the "clear and elegant" (for lack of
>better wording) ADT based structure I like so much in Ada. 

I had no idea I was using a factory when I designed a symbol table class,
but there you go.  I have a root class, with abstract versions of Insert,
First, Next, Exists, that sort of thing.  Actually, there's another
hierarchy of constraint objects that let you search for more specific
things, but anyway.  Currently, there are two derived types; one for
a hashed symbol table, and one for a linked list table.  Once you've
created a table using the appropriate function in the child package,
you don't need to worry about which version you're using, which makes
using it much nicer.

Certainly, they're implemented as access types, but I found that Ada 95's
support for this paradigm made that practically invisible.  In fact, it
*is* invisible.  Consider:

   T  : Table := Tables.Hashed.New_Table ( ... );
   E  : Table_Entry;
   Insert (T, E);
   E := First (T, "x");
   E := Next (T, "x");

Sure, there's a "type Table is access all Root_Table_Type'Class" in one
of the specs, but the only thing you have to know is that Table is
declared somewhere.

Dispatching is obviously essential to the way this works, but I don't
see how you use the Factory pattern without it.

Fraser.
(change the i's to y's to get my real email address)

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Rego, P.]

Em quinta-feira, 4 de março de 1999 05h00min00s UTC-3, Matthew Heaney  escreveu:
> I have prepared a short article on how to implement the Abstract Factory
> pattern in Ada95, and posted it to the ACM patterns archive.  The
> introduction of the article appears below.
> 
> <http://www.acm.org/archives/patterns.html>
> 
> I've been slowly converting the C++ examples in the book Design Patterns
> to Ada95.  In each article I discuss the pattern, explain how to
> implement it in Ada, and explore various idioms and language features.
> A complete, working example with all the code is included.
> 
> You can subscribe to the patterns list by sending a message with the
> body:
> 
> subscribe patterns <your full name>
> 
> to the ACM mailing-list server.
> 
> <mailto:list...@acm.org>
> 
Matt, does this list yet exist?

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Simon Wright]

"Rego, P." <pvrego@gmail.com> writes:

> Em quinta-feira, 4 de março de 1999 05h00min00s UTC-3, Matthew Heaney  escreveu:
>> I have prepared a short article on how to implement the Abstract Factory
>> pattern in Ada95, and posted it to the ACM patterns archive.  The
>> introduction of the article appears below.
>> 
>> <http://www.acm.org/archives/patterns.html>
>> 
>> I've been slowly converting the C++ examples in the book Design Patterns
>> to Ada95.  In each article I discuss the pattern, explain how to
>> implement it in Ada, and explore various idioms and language features.
>> A complete, working example with all the code is included.
>> 
>> You can subscribe to the patterns list by sending a message with the
>> body:
>> 
>> subscribe patterns <your full name>
>> 
>> to the ACM mailing-list server.
>> 
>> <mailto:list...@acm.org>
>> 
> Matt, does this list yet exist?

That was a long timne ago! Try
http://www.adapower.com/index.php?Command=Class&ClassID=Patterns&Title=Patterns

I get the impression that the ACM patterns list is no longer there.

Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive

[Rego, P.]

Thanks Simon :-)