Title: Response To "Patterns - The Abstract Factory" (Francis Glassborow, Overload 30)

Dear Editor,

First of all I must say how much I dislike this sort of cross-over example. It just traps us in the same sort of fruitless discussion as the square is-a rectangle stuff.

For my money the thing not to lose sight of is the fact that this is computer programming. That is, we are attempting to persuade, cajole, and browbeat a box of bits into performing some sort of work. As we are human beings that task is eased by making a model which approaches the concrete world. But, and this is a big but, it must needs be an abstraction and should be focussed on the behaviour we are aiming for.

How then can I even attempt critical thought about Kitchen Tools? What is attachment meant to convey? Supply of mechanical power? What then of modelling supply of electrical power to the Food Mixer? Is a Food Mixer a Kitchen Tool? Even if it is currently a supply of mechanical power?

I can't begin to conjecture whether conjuring up duplicates of kitchen tools using cloning is sane or useful (or ethical) because we have no frame of reference.

Perhaps we are attempting to build some sort of 'numerical theorem prover' in an algebra of kitchen appliances? No. What we are attempting is to show the utility, or otherwise of a pattern in computer programming, the Abstract Factory. Which is now being challenged by the Pluggable Factory, in an effort to reduce coupling if I follow Mr Vlissides correctly.

So what good can come of reading the interfaces with a critical eye? No requirements spec, no sanity check. Using an apparently familiar domain is not an adequate substitute for a simple statement of intent. Still. Here goes.

What gets everybody, at least at first? Still a topic generating articles in C++ Report too. Lifetimes, Ownership, Pointers and Leaks. So we look at constructors and clone.

"The concept of a KitchenTool is clearly not something that should be passed by value." So we prevent accidental copies and allow deliberate ones. This is laudable, all guards against our inevitable errors are to be considered a Good Thing. This is a difficult enterprise and we all need the help we can get or provide for ourselves.

But what reference does clone return? How do we guarantee never to throw from copy construction? Why is clone not const? Why do we need destroy when the destructor is visible, it allows us to attempt to call delete on non dynamic instances even more easily.

Then the factory produces pointers to kitchen tools and the poor old class user is to manage their lifetimes. They won't. The kitchen cupboards will be full of gadgets that no one has any memory of, nor any responsibility for, nor worse yet, any permission to destroy.

Of course clone also returns a bare, unmanaged, unmanageable pointer thinly disguised.

We are asked to conjecture about Attachable, and how attachment should be provided. If the behaviour of the FoodMixer is to modified I can with a certainty say that it should be told about attachments applied. If only the question of motive force for the attachment is considered then only its state, however represented, is concerned.

Also lurking in here is the problem of access to our factory. If we want to assure ourselves that only compatible kitchen tools are available we want one point of access to one type of factory. Otherwise somewhere in the depths of the program one of our team without a bean slicer to hand will need one, and will conjure an arbitrary one, or an arbitrary factory.

Dear Fellow Editor,

I think that Chris Southern's criticism rather misses the point of my humble attempts to elucidate the 'Abstract Factory Pattern'. In my more irritable moments I wonder why he was not writing a full article in response.

The focus of my article was intended to be the Abstract Factory and not implementing KitchenTools. Yet to my view the burden of his criticism is on my implementation. I only wish I had the time to do a fully worked out specification and implementation. I do not, not even for columns for which I am paid.

I know that there are all kinds of half-baked pieces of code floating around in my article. I am not sure why I had a destroy() function, only that it must have seemed a good idea at something past mid-night when that article was mostly written.

The concept of clone functions seems entirely reasonable to me, what seems unreasonable to me is things people call objects that have public copy semantics. From my viewpoint anything with public copy semantics is a value. However I certainly may want to explicitly produce an object as a copy of another one. There is room for an article on how such a clone function should work and perhaps one day I will have time to put a few tentative ideas down for others to critique.

I guess that Abstract Factories should be singletons, but when we (me and the reader) are trying to understand one idea, it is probably enough to tackle just one idea. Once we understand an Abstract Factory it becomes fairly obvious that a program will only need one.

Perhaps next time Chris has time to do some typing he might consider a rather more constructive contribution. I am still not clear whether he fundamentally objects to the concept of an Abstract Factory, to my choice of idea to get to grips with it or just to details of my implementation. Perhaps he objects to all three.

Francis Glassborow