Patron GoF: Factoría ¿Como y cuando se usa?

[axesys]

En el Delphi 2007 vienen unos patrones de factorías que dicen los siguiente:

Abstract Factory

Intent
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Participants

AbstractFactory declares an interface for operations that create abstract product objects.

ConcreteFactory implements the operations to create concrete product objects.

AbstractProduct declares an interface for a type of product object.

ConcreteProduct defines a product object to be created by the corresponding concrete factory.
implements the AbstractProduct interface.

Consequences
The Abstract Factory pattern has the following benefits and liabilities:

It isolates concrete classes. The Abstract Factory pattern helps you control the classes of objects that an application creates. Because a factory encapsulates the responsibility and the process of creating product objects, it isolates clients from implementation classes. Clients manipulate instances through their abstract interfaces. Product class names are isolated in the implementation of the concrete factory; they do not appear in client code.

It makes exchanging product families easy. The class of a concrete factory appears only once in an application-that is, where it's instantiated. This makes it easy to change the concrete factory an application uses. It can use different product configurations simply by changing the concrete factory. Because an abstract factory creates a complete family of products, the whole product family changes at once.

It promotes consistency among products. When product objects in a family are designed to work together, it's important that an application use objects from only one family at a time. AbstractFactory makes this easy to enforce.

Supporting new kinds of products is difficult. Extending abstract factories to produce new kinds of Products isn't easy. That's because the AbstractFactory interface fixes the set of products that can be created. Supporting new kinds of products requires extending the factory interface, which involves changing the AbstractFactory class and all of its subclasses.

Factory Method

Intent
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Participants

Product defines the interface of objects the factory method creates.

ConcreteProduct implements the Product interface.

Creator declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object.
may call the factory method to create a Product object.

ConcreteCreator overrides the factory method to return an instance of a ConcreteProduct.

Consequences
Factory methods eliminate the need to bind application-specific classes into your code. The code only deals with the Product interface; therefore it can work with any user-defined ConcreteProduct classes.
A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object. Subclassing is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution.
Here are two additional consequences of the Factory Method pattern:

Provides hooks for subclasses. Creating objects inside a class with a factory method is always more flexible than creating an object directly. Factory Method gives subclasses a hook for providing an extended version of an object.

Connects parallel class hierarchies. In the examples we've considered so far, the factory method is only called by Creators. But this doesn't have to be the case; clients can find factory methods useful, especially in the case of parallel class hierarchies.

Y este es el código que te generan

unit AbstractFactory;

interface

type
  IAbstractProduct = interface
  end;

  IAbstractFactory = interface
    function CreateIAbstractProduct: IAbstractProduct;
  end;

  TConcreteProduct = class(TInterfacedObject, IAbstractProduct)
  end;

  TConcreteFactory = class(TInterfacedObject, IAbstractFactory)
  public
    function CreateIAbstractProduct: IAbstractProduct;
  end;

implementation

function TConcreteFactory.CreateIAbstractProduct: IAbstractProduct;
begin
  Result := TConcreteProduct.Create();
end;

end.

unit FactoryMethod;

interface

type
  IProduct = interface
  end;

  TConcreteProduct = class(TInterfacedObject, IProduct)
  public
    constructor Create;
  end;

  TCreator = class
   abstract
  public
    function FactoryMethod: IProduct;virtual;abstract;
    procedure SomeOperation;
  end;

  TConcreteCreator = class(TCreator)
  public
    function FactoryMethod: IProduct;override;
  end;

implementation

constructor TConcreteProduct.Create;
begin
  inherited;
  //
  // TODO: Add constructor logic here
  //
end;

procedure TCreator.SomeOperation;
var
  Product1 :IProduct;
begin
  // ...
  Product1 := FactoryMethod();
  // ...
end;

function TConcreteCreator.FactoryMethod: IProduct;
begin

  Result := TConcreteProduct.Create();
end;

end.

[[Delphius]]

Muchas gracias axesys por tu ayuda.
Eso responde parcialmente mi duda... y tal parece que es posible que las interfaces me den una buena solución o al menos una idea.

Lástima que no poseo Delphi 2007 como para probar lo que dices, pero como haz expuesto el código... es fácil trasladarlo...

Se me hace dificil dedicarme en los siguientes días debido a la fiesta de fin de año, seguido de otro acontecimiento que no viene al caso exponer (pero que ya muchos posiblemente se lo imaginan) y a que comienzo mi jornada laboral...

Asi que hasta más o menos el 5 de enero no veré demasiado código. Ando aprovechando estos momentos de ocio porque dentro de poco vuelvo a alejarme de una PC por un buen tiempo.

Estaré escuchando alternativas y opiniones.
Saludos,