|
![](/i/fill.gif) |
Fredrik Eriksson wrote:
> On Mon, 26 Apr 2010 19:10:18 +0200, Darren New <dne### [at] san rr com> wrote:
>> Fredrik Eriksson wrote:
>>> Decentralization is not the purpose of the Factory pattern.
>>
>> Uh, sure it is, in the same sense that inheritance is
>> decentralization. What do *you* think it's for? Maybe it's good for
>> something else too.
>
> Perhaps a poor choice of words on my part. I would say that the Factory
> pattern is about decoupling/abstraction, but I suppose you could call
> that decentralization.
Yeah. My thought was that the factory pattern is there to support the basic
idea of multiple implementations of the same concept. You have a class
called "data connection", and depending on the parsing of the URL you pass
at instantiation, you either get back a subclass that's "http connect" or
"ftp connection" or "https connection" or whatever.
Decentralizing which of those subclasses is chosen is something that's not
automated in any language I know of. Decentralizing the method dispatch to
the appropriate methods of the subclass once instantiated *is* automated.
> My point was that the issue of having to lump information about all the
> concrete classes together in one place is orthogonal; the Factory
> pattern is not intended to decentralize that part, even if you *can*
> sometimes do it.
Right. And that's just my point. I'm saying "the factory pattern could be
made more useful if there were explicit language support for it", just like
dyanmic dispatch or Singleton pattern is more useful when there's explicit
language support.
>> Altho, I suppose with MI (so you can inherit the "Factory" methods
>> anywhere) and static library initialization (so you can invoke those
>> implicitly to do registration when the class gets loaded) you could
>> come very close to doing this with nothing but a library.
>
> MI is not necessary -- nor even helpful -- for this.
My thought was that you could have a "Factory" mix-in that during
initialization would register itself with the appropriate subclass, and then
the "Factory" base class would invoke the routine it knew was in each
factory subclass because it knows it's in the factory mix-in. I.e., you
could automate it much better by having a lump of routines and data that
with a simple declaration get incorporated into your class without you
having to worry about it. Then all you'd have to do is (for example) parse
the URL and see if the scheme is one you handle, rather than writing the
same code to register yourself in the superclass' list of classes to try, etc.
You could do the same thing at runtime with a sufficiently powerful
reflection library, I suppose, but that would seem to be overhead that you
could cure at either compile time or load time (if you wanted to dynamically
load new libraries for new schemas as necessary).
Remember, subroutines are a design pattern. Stacks are a design pattern. OOP
is a design pattern. Exceptions are a design pattern. It's all design
patterns until your language builds it in.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
![](/i/fill.gif) |