How do you enforce use of dedicated factories?
-
It prevents developers from using the class in a way that is not intended. This prevents the more junior developers in the project from doing things in a way the architect does not want the developers to do. Just like when an Architect defines what projects can reference other projects. A good case would be when there are different implementations of an interface/abstract class, depending on some state information, and the this way the instantiating software does not have to know the details of which concrete type that is being instantiated. This is why ADO used software factories. If a developer then bypasses the factory, a bug could be introduced that the architect worked very hard to avoid. To give another case: something I disagree with but also agree with is only being able to inherit from a single class. I can see cases where it would be very advantageous to allow multiple inheritance. This could be considered somewhat arbitrary, like preventing instantiation of a class without using a factory.
“Microsoft has been championing Software Factories to address the challenges of software development”
This indicates that Microsoft is a strong supporter of Factories. I am not an architect, so I am not an expert on architecting applications, and so am not as familiar as I probably should be in how factories are a good tool in creating good software architecture. Check out: http://en.wikipedia.org/wiki/Factory_method_pattern[^]
Are you sure your qoute isn't referring to this instead: [Software Factory^]
-
Hi all, I am a fan of factory and interface driven development but often find myself working amongst people i do not trust to stick to such patterns. As a result i have taken to using a couple of techniques to ensure instantiation happens via factories: 1. Private nested concrete implementations In this approach i have the default concrete implementation of an interface decalred as private nested classes within the factory an exposed as interfaces
public interface IFoo{};
private static class FooFactory
{public static IFoo CreateFoo() { return new Foo(); } private class Foo : IFoo { public Foo(){}; }}
2. Protected constructors with nested subclass I came up with this approach as i needed to work with concrete classes (due to quirks of operator overloads) but still did'nt want the classes instantiated outside of the factory. The concrete class is publicly available but has a protected constructor. within the factory is a subclass of the concrete class that makes the constructor available to the factory
public class Foo
{
protected Foo(){};
}public static class FooFactory
{
public static Foo CreateFoo()
{
return new FooProvider();
}private class FooProvider : Foo { public FooProvider(){} }}
What techniques do everyone use to enforce use of a singleton factory? or do you simply trust your fellow developers to do things properly?
Pedis ex oris Quidquid latine dictum sit, altum sonatur
You could mark the constructor as obsolete with a message pointing people to the factory. Then use a pragma to suppress the warning in your factory when you call the constructor. It might look a bit ugly, but it will clearly point developers to the correct usage. Sometimes practical and explicit is more important than pretty. :) For the discussion about using your pattern in the first place - Typically I would lean more towards an interface in Java and an abstract base class in .NET. This is what the respective developers would expect, and there are actually very good reasons for this difference as there are fundamental differences between the languages in this area.