uncutstone wu wrote:
> I fully don°«t agree with the author°«s opinion.  I think what abstract 
> factory does is to shield clients who need create object from the 
> object°«s concrete type, but not to shield the abstract factory itself 
> from concrete type.
> Acctually ,abstract factory will have the knowledge of the concrete type 
> and shield the client of abstract factory from the concrete type .
> 
> But what the code does is opposite. The abstract factory(here is 
> create_something) does°«t know concrete type, and the client will give 
> that info to it every time the client need a object. It°«s toally 
> misunderstanding of abstract factory.

The way I understood the examle is that "create_something" IS the 
client.  It gets passed the abstract factory (parameter named factory) 
and is actually shielded from the concrete class of the factory.  The 
example is confusing in that the client immediately passes the created 
object to the calling context (which is where the concrete factory is 
know), but the comments seem to make it clear the intention of the 
author.

My problem with the example is that it doesn't solve the same problem as 
the classical GOF Abstract Factory pattern.  In the GOF pattern, the 
abstract factory is able to build a set of related classes, not just a 
single class.  This is used (for example) in windowing systems where you 
want to be able to create a set of related widgets (e.g. GtkButton and 
GtkScrollbar, or QtButton and QtScrollbar).  The example completes 
misses that part of the pattern.

-- Jim Weirich



-- 
Posted via http://www.ruby-forum.com/.