Question

I’m writing a framework for business objects.. I’m heavily using interfaces because of:

1) Automatic memory management
2) Separation of concerns

Usually constructors have a few parameters that are objects of the framework, but I can’t put them in the interfaces.

My question is, if I’m using interfaces to make a separation of concern of the classes that implements them, why my code ends up binded still to the concrete class that implements the interface to call the constructor and its parameters.. and

What’s the merit of putting the creator code in a factory method? (something I’m still not using..)

Thanks!

=== EDIT ===

The point in my question are the constructor’s paremeters.. In the framework lots of objects needs a few other to work.. The answers adress well the point of separation of concerns, but still I don’t see how the solve the problem of parameters..

If I don’t go the constructor way, I should go the “procedure Initialize” way (in the interface) and “CheckObjectInitialized” (protected) in every method of the object.. how this will be cleaner?

Answer 1

The Factory method will allow you to register implementors of your interfaces in a single place and allow the rest of your code to “just ask for an implementor.”

Factory.GetImplementorOf(IMyInterface)

which then returns an interface reference.

It is up to you how you want to implement the factory. You could create new instances for every interface requested, maintain a pool of already created instances and return references to those, or do a mix depending on the interface requested.

You can also decide whether you want your factory to allow multiple implementors of the same interface (how do you select the right one then) or enforce a single implementor for every interface, or a mix.

Multiple instances can come in handy for example when dealing with duplicate(d) services that maybe unavailable at times so you can pick one that happens to be up.

It may also be an idea to provide a GetImplementorOf(array of Interfaces). So you can have multiple implementors of IDump but distinguish amongst them by the way they dump information: for example an implementor that IDump’s an object to IHTML format.

---

are factories prepared to work with constructors parameters in some
clean way??

Well now, that is an interesting question. No, in and of themselves they are not. Factories usually work with a standard constructor perhaps taking an “Owner” and/or “Id” parameter.

If you want more specific constructors on a per class base, you have to

• create more factories, which defeats the purpose of having a single point to register implementors of interfaces
• allow for initialization methods on a per interface/class basis that should be called immediately after construction, which opens up your code to forgetfullness and makes classes less immutable.
• or come up with a way to incorporate constructor signature knowledge into the factory.

At one stage I chose the third option. By creating a factory that

• required registration of an interface with abstract base class
• required implementors to descend from the abstract base class
• returned implementors as a metaclass reference instead of an instance

    TFactory = class(...)
    public
      procedure RegisterInterface(const aGUID: TGUID; const aAbstractBase: TClass);
      procedure RegisterImplementor(const aGUID: TGUID; const aImplementor: TClass);
      function GetImplementor(const aGUID: TGUID): TClass;

Drawbacks:

• It is quite a drag to have to declare both an interface and an abstract base class.
• It defeats the “multiple inheritance by interface” advantage of interfaces in a single inheritance language.
• You need to spread knowledge of the interface/abstract base class pair throughout your code otherwise you still can’t use the class specific constructors. Generics might help here but I haven’t yet looked into that.
• It serves no real purpose if you do not have multiple implementors of the same (set of) interfaces.
• Even if you want multiple implementors just for unit testing, it seems overkill. I have found dummy classes declared in the test unit with the relevant parts of the class’s interface to be more helpful and effective.

All in all I have gone back to the standard constructor / specific Initialization pair method. It should be fairly easy to write a code scanning unit test to check that every GetImplementor call from the factory is followed by an Initialization call. And though the class in theory is no longer as immutable as it would be with a specific constructor, it still is for all practical purposes. And if you want to ensure that the Initialize method is only called right after construction, that should be easy to add.