From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,386670df95abccf1 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: ANNOUNCE: Abstract Factory posted to ACM patterns archive Date: 1999/03/09 Message-ID: #1/1 X-Deja-AN: 452843089 Sender: matt@mheaney.ni.net References: <7bmcb5$jkf$1@nnrp1.dejanews.com> NNTP-Posting-Date: Mon, 08 Mar 1999 20:15:14 PDT Newsgroups: comp.lang.ada Date: 1999-03-09T00:00:00+00:00 List-Id: 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. 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.