Let's say I want to build a list of strings (Which is not the real scenario case, but sounds simpler to explain).
I'd have an interface for my list of strings factory that would look like this
public interface IStringsListFactory{
List<string> Create();
}
But lets say one of my concrete factory would require to get this list of string from a file/database etc..
public class StringsListFromFile : IStringsListFactory{
private StreamReader _streamReader;
public StringsListFromFile(StreamReader sr) //StreamReader is just an example.
{
_streamReader = sr;
}
public List<string> Create(){
///recover the strings using my stream reader...
}
}
I know this approach would work, but I was wondering if it breaks the Factory Pattern to pass parameters to the factory's constructor so I wouldn't break my interface. Are there any counterparts to doing this? Is there another solution I didn't think of? Am I asking too many questions!?! (Yeah, I know the answer to this one!)
Parameter in constructor, and constructor itself, should only do one and only one job to do: that is registering dependency. Sometimes, it is needed to "inject" the dependency to factory, as described at abstract factory pattern by Mark Seeman in this answer.
public class ProfileRepositoryFactory : IProfileRepositoryFactory
{
private readonly IProfileRepository aRepository;
private readonly IProfileRepository bRepository;
public ProfileRepositoryFactory(IProfileRepository aRepository,
IProfileRepository bRepository)
{
if(aRepository == null)
{
throw new ArgumentNullException("aRepository");
}
if(bRepository == null)
{
throw new ArgumentNullException("bRepository");
}
this.aRepository = aRepository;
this.bRepository = bRepository;
}
public IProfileRepository Create(string profileType)
{
if(profileType == "A")
{
return this.aRepository;
}
if(profileType == "B")
{
return this.bRepository;
}
// and so on...
}
}
It is valid in that case, but not in your case because:
It makes your factory have state
It makes your factory more flexible if the parameter (stream) injected as method parameter
public class StringsListFromFile : IStringsListFactory{
public List<string> Create(StreamReader sr){
///recover the strings using my stream reader...
}
}
If your interface should be flexible for the input, use generic instead
additionally, it is better to return IEnumerable<string> instead of List<string>
You could abstract away the implementation of whatever retrieves it. I would also personally pass it through into the method instead of the constructor:
public interface IFactoryDataSourceProvider<T> {
IList<T> GetData();
}
public class IStringListFactory {
public IList<string> Create(IFactoryDataSourceProvider<string> provider) {
return _provider.GetData();
}
}
Then perhaps:
class StreamReaderDataProvider : IFactoryDataSourceProvider<string> {
public IList<string> GetData() {
using (var streamReader = new StreamReader( ... )) {
return streamReader.ReadAllLines(); // etc.
}
}
}
var list = factory.Create(new StreamReaderDataSourceProvider());
This all seems silly for such a small sample.. but I assume this isn't quite as small as your example is.
Factory Pattern forces you to use Default Constructor.
Using a parametric constructor violates the idea of using factory pattern since the object will not return the valid state to the caller class. In your case, you have to initialize them after the factory class call. This will duplicate your code and the idea of using the factory pattern is to avoid the code duplication.
But again I am not familiar with the whole scenario. But as per your set up shown here you should use a method in place of Parametric Constructor.
Related
Ok this is driving me crazy! I have a generic method in a generic class.
public interface IHandler<T> where T : class
{
T[] parseCSV(string InputFileName)
}
public class Handler<T> : IHandler<T> where T : class
{
public T[] parseCSV(string InputFileName)
{
if (File.Exists(InputFileName))
{
_inputFileName = InputFileName;
var Engine = new FileHelperEngine<T>();
return Engine.ReadFile(_inputFileName);
}
else
{
throw new IOException($"{InputFileName} not found!");
}
}
}
I have registered the generic in a IoC container as such:
container.RegisterType(typeof(IHandler<>), typeof(Handler<>));
Along with several mappers to parse files with the FileHelpers package
container.RegisterType<IMapper1, Mapper1>();
container.RegisterType<IMapper2, Mapper2>();
container.RegisterType<IMapper3, Mapper3>();
My container is legit for the majority of my app, and I can instate the IHandler object.
IHandler<IMapper1> Handler1 = container.Resolve<IHandler<IMapper1>>();
However, I cannot figure out how to pass the IMapper1 object into the generic parseCSV method so it will resolve in FileHelperEngine.
Does anyone know how to pass the Mapper object to FileHelperEngine using Unity? I would like to get that dependency off of the client code.
You have a dependency in your parseCSV method. Therefore, you should inject that into your class as well. There are many ways to do that but I prefer, and I have seen many other devs also prefer, constructor injection.
Thus all you need is an interface and then inject an instance of a class which implements the interface into your constructor like this:
public interface IFileHelperEngine<T> where T : class
{
T[] ReadFile(string inputFileName);
}
public class Handler<T> : IHandler<T> where T : class
{
private IFileHelperEngine<T> fileHelperEngine;
public Handler(IFileHelperEngine<T> fileHelperEngine) //<----See this.
{
this.fileHelperEngine = fileHelperEngine;
}
public T[] parseCSV(string InputFileName)
{
if (File.Exists(InputFileName))
{
_inputFileName = InputFileName;
return this.fileHelperEngine.ReadFile(_inputFileName); //<--and this
}
throw new IOException($"{InputFileName} not found!");
}
}
This is actually good because now you can mock the IFileHelperEngine when you are unit testing the Handler<T> class.
FYI, you are not using .NET naming conventions; Locals should use camel case notation and method names should use Pascal Notation.
I've asked myself this question and I'm still not done thinking about this.
What I am thinking about
When you have a strategy pattern, a lot of implementations also use a factory pattern to retrieve a specific strategy. Most factory examples on the internet make use of a switch or if statement. This works perfectly when you do not often change or add strategies. But what if the factory is used to dynamically find a strategy and the strategies are changed and added often. Then this is a full time job for the programmer. Now I have a situation where I just want to add a new strategy without having to change the factory. In other words how do you implement the factory pattern so it dynamically searches for a strategy. And how can I list all available strategies.
The problem
When I look for this on the internet I can't find a good proper solution. I am thinking about using a reflection library to do this but it is not recommended to use reflection everywhere I look. So how to implement a dynamic factory. Or is there an other pattern for this purpose?
Example
The strategies:
The factory:
public enum StrategyName { ImplementedStrategy1, ImplementedStrategy2, ImplementedStrategy3 };
public class StrategyFactory
{
public static Sniffer getInstance(StrategyName choice) {
Strategy strategy = null;
switch (choice) {
case StrategyName.ImplementedStrategy1:
strategy = new ImplementedStrategy1();
break;
case StrategyName.ImplementedStrategy2:
strategy = new ImplementedStrategy2();
break;
case StrategyName.ImplementedStrategy3:
strategy = new ImplementedStrategy3();
break;
}
return strategy;
}
}
Now how can I make this dynamic? Or why shouldn't I?
Have your ImplementedStrategy contract include a IsGoodMatch(params) method. Then you just iterate over your collection of strategies, calling IsGoodMatch on each one until you get one (or many) results, and then you use that strategy(ies).
I am not sure if this will help but here is what i am thinking.
You have
public class ImplementedStrategy1 : Strategy
{
}
public class ImplementedStrategy2 : Strategy
{
}
etc..
Then you make an attribute class [StrategyName(StrategyName.EnumValue)].
More details here https://msdn.microsoft.com/en-us/library/aa288454(v=vs.71).aspx
So, now we get
[StrategyName(StrategyName.EnumValue1)].
public class ImplementedStrategy1 : Strategy
{
}
[StrategyName(StrategyName.EnumValue2)].
public class ImplementedStrategy2 : Strategy
{
}
Then, in public static Sniffer getInstance(StrategyName choice) instead of the switch,using reflection, you get all the types that inherit from Strategy and check if the choice parameter matches the custom attribute value.
Now you just need to create a new instance for that type.
When this is done and you wish to add a new strategy, you just have to create the new class with the attribute and add a new value to the enum.
Let me know if you need any help with the implementation.
Not sure if you still need this but it can be achieved in Java as below.
public interface Strategy {
boolean isGoodMatch(StrategyName strategyName);
}
public class ImplementedStrategy1 implements Strategy {
#Override
public boolean isGoodMatch(StrategyName strategyName) {
return strategyName == StrategyName.ImplementedStrategy1;
}
}
public class ImplementedStrategy2 implements Strategy {
#Override
public boolean isGoodMatch(StrategyName strategyName) {
return strategyName == StrategyName.ImplementedStrategy2;
}
}
public class ImplementedStrategy3 implements Strategy {
#Override
public boolean isGoodMatch(StrategyName strategyName) {
return strategyName == StrategyName.ImplementedStrategy3;
}
}
public class StrategyFactory {
private List<Strategy> strategies;
public StrategyFactory(List<Strategy> strategies){
this.strategies = strategies;
}
public Strategy getInstance(StrategyName choice){
Strategy strategyChoice = null;
for (Strategy strategy: this.strategies){
if(strategy.isGoodMatch(choice))
strategyChoice = strategy;
}
return strategyChoice;
}
}
If you wanted you could use streams in the getInstance method.
public Strategy getInstance(StrategyName choice){
return strategies
.stream()
.filter(x -> x.isGoodMatch(choice))
.findFirst()
.get();
}
You can provide the list to the factory by using a DI container as mentioned above. If you are using something like Spring you could use #Autowire annotation.
http://www.baeldung.com/spring-autowire
If I have the following code:
public class RobotNavigationService : IRobotNavigationService {
public RobotNavigationService(IRobotFactory robotFactory) {
//...
}
}
public class RobotFactory : IRobotFactory {
public IRobot Create(string nameOfRobot) {
if (name == "Maximilian") {
return new KillerRobot();
} else {
return new StandardRobot();
}
}
}
My question is what is the proper way to do Inversion of Control here? I don't want to add the KillerRobot and StandardRobot concretes to the Factory class do I? And I don't want to bring them in via a IoC.Get<> right? bc that would be Service Location not true IoC right? Is there a better way to approach the problem of switching the concrete at runtime?
For your sample, you have a perfectly fine factory implementation and I wouldn't change anything.
However, I suspect that your KillerRobot and StandardRobot classes actually have dependencies of their own. I agree that you don't want to expose your IoC container to the RobotFactory.
One option is to use the ninject factory extension:
https://github.com/ninject/ninject.extensions.factory/wiki
It gives you two ways to inject factories - by interface, and by injecting a Func which returns an IRobot (or whatever).
Sample for interface based factory creation: https://github.com/ninject/ninject.extensions.factory/wiki/Factory-interface
Sample for func based: https://github.com/ninject/ninject.extensions.factory/wiki/Func
If you wanted, you could also do it by binding a func in your IoC Initialization code. Something like:
var factoryMethod = new Func<string, IRobot>(nameOfRobot =>
{
if (nameOfRobot == "Maximilian")
{
return _ninjectKernel.Get<KillerRobot>();
}
else
{
return _ninjectKernel.Get<StandardRobot>();
}
});
_ninjectKernel.Bind<Func<string, IRobot>>().ToConstant(factoryMethod);
Your navigation service could then look like:
public class RobotNavigationService
{
public RobotNavigationService(Func<string, IRobot> robotFactory)
{
var killer = robotFactory("Maximilian");
var standard = robotFactory("");
}
}
Of course, the problem with this approach is that you're writing factory methods right inside your IoC Initialization - perhaps not the best tradeoff...
The factory extension attempts to solve this by giving you several convention-based approaches - thus allowing you to retain normal DI chaining with the addition of context-sensitive dependencies.
The way you should do:
kernel.Bind<IRobot>().To<KillingRobot>("maximilliam");
kernel.Bind<IRobot>().To<StandardRobot>("standard");
kernel.Bind<IRobotFactory>().ToFactory();
public interface IRobotFactory
{
IRobot Create(string name);
}
But this way I think you lose the null name, so when calling IRobotFactory.Create you must ensure the correct name is sent via parameter.
When using ToFactory() in interface binding, all it does is create a proxy using Castle (or dynamic proxy) that receives an IResolutionRoot and calls the Get().
I don't want to add the KillerRobot and StandardRobot concretes to the Factory class do I?
I would suggest that you probably do. What would the purpose of a factory be if not to instantiate concrete objects? I think I can see where you're coming from - if IRobot describes a contract, shouldn't the injection container be responsible for creating it? Isn't that what containers are for?
Perhaps. However, returning concrete factories responsible for newing objects seems to be a pretty standard pattern in the IoC world. I don't think it's against the principle to have a concrete factory doing some actual work.
I was looking for a way to clean up a massive switch statement that returned a C# class to do some work (code smell here).
I didn't want to explicitly map each interface to its concrete implementation in the ninject module (essentially a mimic of lengthy switch case, but in a diff file) so I setup the module to bind all the interfaces automatically:
public class FactoryModule: NinjectModule
{
public override void Load()
{
Kernel.Bind(x => x.FromThisAssembly()
.IncludingNonPublicTypes()
.SelectAllClasses()
.InNamespaceOf<FactoryModule>()
.BindAllInterfaces()
.Configure(b => b.InSingletonScope()));
}
}
Then create the factory class, implementing the StandardKernal which will Get the specified interfaces and their implementations via a singleton instance using an IKernal:
public class CarFactoryKernel : StandardKernel, ICarFactoryKernel{
public static readonly ICarFactoryKernel _instance = new CarFactoryKernel();
public static ICarFactoryKernel Instance { get => _instance; }
private CarFactoryKernel()
{
var carFactoryModeule = new List<INinjectModule> { new FactoryModule() };
Load(carFactoryModeule);
}
public ICar GetCarFromFactory(string name)
{
var cars = this.GetAll<ICar>();
foreach (var car in cars)
{
if (car.CarModel == name)
{
return car;
}
}
return null;
}
}
public interface ICarFactoryKernel : IKernel
{
ICar GetCarFromFactory(string name);
}
Then your StandardKernel implementation can get at any interface by the identifier of you choice on the interface decorating your class.
e.g.:
public interface ICar
{
string CarModel { get; }
string Drive { get; }
string Reverse { get; }
}
public class Lamborghini : ICar
{
private string _carmodel;
public string CarModel { get => _carmodel; }
public string Drive => "Drive the Lamborghini forward!";
public string Reverse => "Drive the Lamborghini backward!";
public Lamborghini()
{
_carmodel = "Lamborghini";
}
}
Usage:
[Test]
public void TestDependencyInjection()
{
var ferrari = CarFactoryKernel.Instance.GetCarFromFactory("Ferrari");
Assert.That(ferrari, Is.Not.Null);
Assert.That(ferrari, Is.Not.Null.And.InstanceOf(typeof(Ferrari)));
Assert.AreEqual("Drive the Ferrari forward!", ferrari.Drive);
Assert.AreEqual("Drive the Ferrari backward!", ferrari.Reverse);
var lambo = CarFactoryKernel.Instance.GetCarFromFactory("Lamborghini");
Assert.That(lambo, Is.Not.Null);
Assert.That(lambo, Is.Not.Null.And.InstanceOf(typeof(Lamborghini)));
Assert.AreEqual("Drive the Lamborghini forward!", lambo.Drive);
Assert.AreEqual("Drive the Lamborghini backward!", lambo.Reverse);
}
I have a question about creating a factory interface with a create method that can cater for accepting different argument types depending on the implementation.
To give you a bit more background, I am using dependency in injection in a project, and require stateful objects to be generated at runtime - therefore I am injecting factories (rather than the objects themselves) to create these stateful objects. The problem I have come across is that, for some interfaces, the concrete implementations simply cannot have the same constructor argument types, and so the factories that create an instance of these interfaces require almost 'dynamic' arguments to be passed to the create method.
I have been going over this for a couple of days, and the following is the best solution I could come up with (namely, passing an object to the factory create method and casting it in the concrete implementation of the factory). I am really looking for feedback from people who have come across this scenario before, to hear what they came up with, and whether or not the solution I am proposing below is acceptable.
Apologies if this is missing any information, and many thanks in advance!
//
// Types...
//
interface IDataStore
{
List<string> GetItems();
}
public class XmlDataStore : IDataStore
{
public XmlDataStore(XmlDocument xmlDoc)
{
// Initialise from XML Document...
}
public List<string> GetItems()
{
// Get Items from XML Doc...
}
}
public class SQLDataStore : IDataStore
{
public SQLDataStore(SqlConnection conn)
{
// Initialise from SqlConnection...
}
public List<string> GetItems()
{
// Get Items from Database Doc...
}
}
//
// Factories...
//
interface IDataStoreFactory
{
IDataStore Create(object obj);
}
class XmlDataStoreFactory : IDataStore
{
IDataStore Create(object obj)
{
// Cast to XmlDocument
return new XmlDataStore((XmlDocument)obj);
}
}
class SQLDataStoreFactory : IDataStore
{
IDataStore Create(object obj)
{
// Cast to SqlConnection
return new SQLDataStore((SqlConnection)obj);
}
}
Based on this comment you need one factory which produces several types of IDataStore. You could accomplish by creating a open generic factory method in the singleton factory instance.
interface IDataStore<TStoreType>
{
void SetBaseType(TStoreType obj);
List<string> GetItems();
}
interface IDataStoreFactory
{
IDataStore<TStoreType> Create<TStoreType>(TStoreType obj)
}
class DataStoreFactory : IDataStoreFactory
{
public IDataStore<TStoreType> Create<TStoreType>(TStoreType obj)
{
if (obj.GetType() == typeof(SqlConnection))
{
var store = new SQLDataStore((SqlConnection)(Object)obj);
return (IDataStore<TStoreType>)store;
}
if (obj.GetType() == typeof(XmlDocument))
{ //... and so on }
}
}
class SQLDataStore : IDataStore<SqlConnection>
{
private readonly SqlConnection connection;
public SQLDataStore(SqlConnection connection)
{
this.connection = connection;
}
public List<string> GetItems() { return new List<string>(); }
}
You can use this factory like this:
var factory = new DataStoreFactory();
var sqlDatastore = factory.Create(new SqlConnection());
var xmlDatastore = factory.Create(new XmlDocument());
Your datastore factory would become a lot less complex if you would use a DI container. You could inject the container in the factory and retrieve your instances directly from the container, which would typically build your instances from bottom to top, including there own dependencies, lifetime management and so on. But be very carefull with this approach, it is the first step to using the service locator pattern which is an anti pattern
Not really sure if I understand your question correctly but to me it sounds a little odd to have factory instances which you use for the creation of your statefull objects as you call them.
To directly answer your question: generics are your solution. You rinterface becomes an open generic abstraction:
interface IDataStore<TStoreType>
{
List<string> GetItems();
}
interface IDataStoreFactory<TStoreType>
{
IDataStore<TStoreType> Create(TStoreType obj);
}
and your factory classes will look like this:
class XmlDataStoreFactory : IDataStoreFactory<XmlDocument>
{
IDataStore<XmlDocument> Create(XmlDocument document)
{
return new XmlDataStore(document);
}
}
class SQLDataStoreFactory : IDataStoreFactory<SqlConnection>
{
IDataStore<SqlConnection> Create(SqlConnection connection)
{
return new SQLDataStore(connection);
}
}
This will work, but from the examples you give I got the impression you're using factories throughout your codebase. Maybe I'm wrong on this point, but look at your design and minimize the number of factories. Needing a factory means mixing data with behaviour and this will always, eventually, get you into trouble.
For example, let's say you have some kind of service which adds the current user to a audit log when he logs in. This service offcourse needs the current user which is a typical example of runtime data (or contextual data). But instead of:
public class AuditLogService
{
public void AddApplicationSignIn(User user)
{
//... add user to some log
}
}
I know this is not a good example because you actually wouldn't need a factory for this class, but with the next code example you'll get the point:
public class AuditLogService
{
private readonly IUserContext userContext;
public AuditLogService(IUserContext userContext)
{
this.userContext = userContext;
}
public void AddApplicationSignIn()
{
var user = this.userContext.GetCurrentUser();
//... add user to some log
}
}
So by splitting data from behaviour you rule out the need for factories. And admitted there are cases where a factory is the best solution. I do think an IDataStore is not something you need a factory for.
For a good blog on splitting data and behaviour read here
I am doing some research on design pattern implementation variants, i have come across and read some examples implemented here http://www.codeproject.com/Articles/37547/Exploring-Factory-Pattern and http://www.oodesign.com/factory-pattern.html. My focus of concern is when implementing factory pattern without reflection . the stated articles said that we need to register objects not classes which seems fine and logical to me but when seeing the implementation i see the duplication of objects e.g in the code below
// Factory pattern method to create the product
public IRoomType CreateProduct(RoomTypes Roomtype)
{
IRoomType room = null;
if (registeredProducts.Contains(Roomtype))
{
room = (IRoomType)registeredProducts[Roomtype];
room.createProduct();
}
if (room == null) { return room; }
else { return null; }
}
// implementation of concrete product
class NonACRoom : IRoomType
{
public static void RegisterProduct()
{
RoomFactory.Instance().RegisterProduct(new NonACRoom(), RoomTypes.NonAcRoom);
}
public void getDetails()
{
Console.WriteLine("I am an NON AC Room");
}
public IRoomType createProduct()
{
return new NonACRoom();
}
}
the method RegisterProduct is used for self registeration, we have to call it anyways before creating factory object i.e before some where in the main class of the client or anywhere applicable that ensure its calling. below is we are creating a new product and in the method above we are creating again a new product which seems non sense. any body comment on that
I have done something similar to this in the past. This is essentially what I came up with (and also doing away with the whole "Type" enumeration):
public interface ICreator
{
IPart Create();
}
public interface IPart
{
// Part interface methods
}
// a sample creator/part
public PositionPartCreator : ICreator
{
public IPart Create() { return new PositionPart(); }
}
public PositionPart : IPart
{
// implementation
}
Now we have the factory itself:
public sealed class PartFactory
{
private Dictionary<Type, IPartCreator> creators_ = new Dictionary<Type, IPartCreator>();
// registration (note, we use the type system!)
public void RegisterCreator<T>(IPartCreator creator) where T : IPart
{
creators_[typeof(T)] = creator;
}
public T CreatePart<T>() where T: IPart
{
if(creators_.ContainsKey(typeof(T))
return creators_[typeof(T)].Create();
return default(T);
}
}
This essentially does away with the need for a "type" enumeration, and makes things really easy to work with:
PartFactory factory = new PartFactory();
factory.RegisterCreator<PositionPart>(new PositionPartCreator());
// all your other registrations
// ... later
IPart p = factory.CreatePart<PositionPart>();
The first creation is used to give something to work on to RegisterProduct. Probably, the cost of that object is neglectable. It's done during initialization and won't matter much.
This instance is required though because in C# you need an object to call createProduct on. This is because you can't use reflection to store a reference to a type instead of a reference to an object.