Re: Which pattern does this conform to?

iamfractal_at_hotmail.com
Date: 01/18/05 

Date: 18 Jan 2005 01:52:23 -0800

Andrew McDonagh wrote:
> Jimmy Cerra wrote:
> > Hi. I've been struggling lately while designing a framework [1,
2], so
> > I examined some existing solutions. I noticed a bunch of
frameworks
> > organized in the following fashion, so I'm wondering if it is a
specific
> > pattern.
> >
> >

[Herr Snipski]

Hi, folks!

I agree with Andrew that you usually don't have direct access to the
concrete factory class; but I usually do allow the user to switch
implementations behind the factory's interface. I usually use a
parameterized factory method for this, so the user can do the
following (if he wishes):

Factory gtkFactory = options.getFactory(Options.GTK_FACTORY);
Factory qtFactory = options.getFactory(Options.QT_FACTORY);

So at least in my applications, the user can play havok by passing
GTK-implementations to QT-implementations.

> > That's not good. It seems to be especially hard to prevent these
kinds
> > of mistakes in languages without built-in templates or generics.
>
>

Engineering is compromise. It's of course, "Not good," if the user
mixes implemenations and causes a program to crash. But the abstract
factory pattern offers the advantage that, if the user is careful, he
can have identical application code working with different toolkit
implementations.

This, of course, you're fully aware of; I just wanted to point out
that it would be rash to dump the abstract factory pattern on the
grounds of any one disadvantage. Not that the OP proposed dumping it,
of course.

Getting back to that, "It seems to be especially hard to prevent these
kinds of mistakes ..." It's especially hard to prevent the user making
all sorts of mistakes. Some of them do it for a living, poor things.

I would say that the answer is good ol' documentation. Tell your users
not to mix impelmentations. They'll still do it, but not for very
long; and you'll be able to say, "Told ya so." The benefit of uniform
access to the different implementations outweighs the cost potential
crashes. If you want type-safe prevention of such crashes, then drop
the abstract factory pattern and, "Program to an implementation, not
an interface." (Ouch.)

Furthermore, the OP asks, "Is there a name for this pattern? Am I
misinterpreting a classic pattern in these cases?"

I don't see a strong pattern in the Window creating the Button, rather
than the factory creating Window and Button itself. Perhaps mild
delegation.

I don't think you're misinterpreting a classic pattern; perhaps you
thought that all design patterns were perfect or flawless: they are
not; they are engineering solutions whose benefits and costs must be
weighed per-application, and whose limitations should not be
overlooked.

Not long now to Episode III. I'd bet Darth wouldn't tolerate users
mixing implementations. "Apologies accepted, user Nieder."
.ed

www.EdmundKirwan.com - Home of The Fractal Class Composition.