Fredrik Eriksson wrote:
> On Mon, 26 Apr 2010 19:10:18 +0200, Darren New <dne### [at] sanrrcom> 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