How do you enforce use of dedicated factories?
-
GParkings wrote:
personally i've always preferred a suite of dedicated singleton factories (providing construction for a category of types) than individual static factory methods on each type. Thats probably personal preference though.
Taste is a lousy argument. Either it helps during the implementation, or it doesn't. What's the use of a factory if it merely hides the constructor? Yes, I agree that they're a nice way of moving the construction to a user-configuration, but you don't need a factory-method in every class to do so; in fact, it'd be overkill, and needless complexity. Needless complexity is usually avoided, as it makes the project harder to maintain, and increases the chance of introducing bugs. If the programmer that's using your classes needs to use a different class based on a configuration, then he'd be the one to build a factory.
Bastard Programmer from Hell :suss:
I think we are getting some crossed wires here , i am actually arguing against a factory method in every class and talkign about a common singleton factory providing factory methods for a group of classes with a common association. Also, and perhaps my initial question was a little misleading, i am not suggesting a factory approach for every class, rather, i was trying to spark a debate on how to enforce use of a factory where one is deemed nescessary/advantageous
Pedis ex oris Quidquid latine dictum sit, altum sonatur
-
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
GParkings wrote:
or do you simply trust your fellow developers to do things properly?
Honestly, it sounds like you are more interested in writing pretentious code that annoys your co-workers and makes their lives more difficult rather then adding value to the project (your words, not mine :)). A good class design is one that is easy to use, implement and maintain. If I was your co-worker and I needed to create an IFactorySelector widget to get an IFactoryCreator instance just so I could create an IMyFactory instance to get a MyButton widget, I'd probably hate working with you :). I'm only saying this because you said several times in your post that you don't trust your co-workers to write code up to your standards :).
-
GParkings wrote:
or do you simply trust your fellow developers to do things properly?
Honestly, it sounds like you are more interested in writing pretentious code that annoys your co-workers and makes their lives more difficult rather then adding value to the project (your words, not mine :)). A good class design is one that is easy to use, implement and maintain. If I was your co-worker and I needed to create an IFactorySelector widget to get an IFactoryCreator instance just so I could create an IMyFactory instance to get a MyButton widget, I'd probably hate working with you :). I'm only saying this because you said several times in your post that you don't trust your co-workers to write code up to your standards :).
ok, i see where my tounge-in-cheek manner of typing up that post may have given that impression. fair enough :) As i stated in another reply, i'm not suggesting a factory for every class. what i was attempting to do with this post was spark a debate over approaches to enforcing/encouraging use of factories where such things are advantageous. i tend to work in dev teams for periods of 6 months, im not around after that to explain how particular classes should be instantiated personally so i aim to make the intended instantiation 'easiest-path' (i do, ofc, write documentation.. the whole last month of my last contract was spent documenting every concept within the code. but i'm the first to admit i don't always reach straight for the docs and things can get overlooked) So, really, rather than trying to write annoying code as you suggest, i am trying to make peoples lives easier by guiding them to the intended use of the code i have written without having to spend hours examining it or reading documentation
Pedis ex oris Quidquid latine dictum sit, altum sonatur
-
I think we are getting some crossed wires here , i am actually arguing against a factory method in every class and talkign about a common singleton factory providing factory methods for a group of classes with a common association. Also, and perhaps my initial question was a little misleading, i am not suggesting a factory approach for every class, rather, i was trying to spark a debate on how to enforce use of a factory where one is deemed nescessary/advantageous
Pedis ex oris Quidquid latine dictum sit, altum sonatur
GParkings wrote:
I think we are getting some crossed wires here , i am actually arguing against a factory method in every class and talkign about a common singleton factory providing factory methods for a group of classes with a common association.
Aye, I misunderstood. In that case, I'd say that they could build a factory as soon as they need it, based on the argument that you don't know beforehand which kind of parameter will be used for the factory to decide on (a string; an enum; a hash), nor which classes that the factory should choose between. You might provide a decent set in your factory, but what if I need to "add" a derived class to that? Yes, I could encapsulate it in a new factory (a new strategy) if I'm passing a different parameter-type, but it would only add even more complexity.
Bastard Programmer from Hell :suss:
-
ok, i see where my tounge-in-cheek manner of typing up that post may have given that impression. fair enough :) As i stated in another reply, i'm not suggesting a factory for every class. what i was attempting to do with this post was spark a debate over approaches to enforcing/encouraging use of factories where such things are advantageous. i tend to work in dev teams for periods of 6 months, im not around after that to explain how particular classes should be instantiated personally so i aim to make the intended instantiation 'easiest-path' (i do, ofc, write documentation.. the whole last month of my last contract was spent documenting every concept within the code. but i'm the first to admit i don't always reach straight for the docs and things can get overlooked) So, really, rather than trying to write annoying code as you suggest, i am trying to make peoples lives easier by guiding them to the intended use of the code i have written without having to spend hours examining it or reading documentation
Pedis ex oris Quidquid latine dictum sit, altum sonatur
I can think of a few times where I'd use the factory method, but it would be to simplify object creation, not to play programming cop :). As another poster mentioned, you can just have your constructors protected if you don't want people creating your objects directly. Writing code full of design patterns makes it less maintainable IMO. I follow some architecture patterns in my code like MVVM and have adopted Dependency Injection, but most of the time, I try to write my public classes so they are completely stand-alone.
-
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
GParkings wrote:
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.
Presumably not because you are over using it. The primary reason for factories is to control the creation idiom.
GParkings wrote:
What techniques do everyone use to enforce use of a singleton factory? or do you simply trust your fellow developers to do things properly?
The use case should make usage easy. If not then something is probably wrong somewhere.
-
I understand your viewpoint but there are situations i which use of a dedicated factory is highly desirable. Some examples i've come across: - choice of concrete class is determined at runtime based on a user-editable configuration file (think spring mappings) - part of the construction logic requires registration to some form of catalog class and other constraints mean that it is better to have the catalog act as a factory and apply logic to the instances it creates than to have the concrete class constructor locate and register with the catalog As for the second approach, i'm aware of the limitations with regards to exposing the constructor through inheritance (as i am aware of the option to access a ctor via reflection), however i would expect anyone finding themselves doing such things to get at a ctor to ask themselves if that class was meant to be directly instantiated. Thats what i am after (perhaps 'enforce' is too strong a word)
Pedis ex oris Quidquid latine dictum sit, altum sonatur
GParkings wrote:
Some examples i've come across:
Those are of course appropriate uses. Most cases do not apply to that. If you have users circumventing that then education is the proper course. Look at it in a different way if they don't know why you are doing that then they might be writing their own code in a way that is inappropriate because they don't understand the alternatives.
-
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
GParkings wrote:
What techniques do everyone use to enforce use of a singleton factory?
In general, without regard to the "singleton" part, I would usually implement a factory such that the factory and class are part of the same project. And the target classes are all internal. The factory is public. Whether the factory is a singleton or not doesn't really have anything to do with that decision.
-
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 have two options, and one requires that the classes be in a separate project. If you have your class and factory in a separate project from the one that is creating instances of the class, then you have have all constructors in the class declared internal.
public class testFactory
{
public static test2 CreateTest()
{
return new test2();
}
}class test2
{
internal test()
{
}
}The option option is to integrate the factory with the class:
class test
{
public static test CreateTest()
{
return new test();
}protected test() { }}
Unlike some other people here, I think there can be really good reasons to want to force using a factory.
-
You have two options, and one requires that the classes be in a separate project. If you have your class and factory in a separate project from the one that is creating instances of the class, then you have have all constructors in the class declared internal.
public class testFactory
{
public static test2 CreateTest()
{
return new test2();
}
}class test2
{
internal test()
{
}
}The option option is to integrate the factory with the class:
class test
{
public static test CreateTest()
{
return new test();
}protected test() { }}
Unlike some other people here, I think there can be really good reasons to want to force using a factory.
-
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[^]
-
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.