views:

31

answers:

2

I have used the abstract factory pattern to help with Dependency Injection and make my project more unit test friendly. A good couple of times I have come across the point that we should return objects in a ready-to-use state. Doing extra work like getting an object's state from a database makes it harder to test unless we can mock out the database layer. So I moved this into a factory. Although at this point I think it should be altered to a builder because I am not returning a family of products, there is only 1 product.

Anyway, I need to ensure that there is only 1 instance of 2 or 3 classes in my application. I did this in the factory. I am avoiding the use of the Singleton pattern because I don't like it. I think it violates OO too much and there are better ways of doing it. It also makes unit testing harding. So my factory contains the single instance of the class. If someone asks for the object I check if I have already created it and return it.

Now I need to add some more functionality. I need to be able to reset the object's state. For example we can change its configuration in the database. Now I need to get hold of that instance and change its internal state to mirror the new configuration. I am not sure if I should stick this into the factory but this seems to violate Single Responsibility Principle. The other alternative is to make an object that knows how to reset that object's state. For example:

class MyObjectResetter
{
    private MyObject myObject;
    private MyDao myDao;

    public MyObjectResetter(MyObject myObject, MyDao myDao)
    {
        this.myObject = myObject;
        this.myDao = myDao;
    }

    public void Reset()
    {
        myObject.Details = myDao.GetDetails();
        myObject.MoreDetails = myDao.GetMoreDetails();
    }
}

Are there any better ideas? Are there any better patterns?

A: 

I would put the reset functionality into the factory as well, as in my view the factory is responsible for providing the needed objects to its clients in general. Reloading the object state from a DB (thus effectively recreating the object with a different state) IMHO fits into this general responsibility.

Péter Török
+1  A: 

So my factory contains the single instance of the class. If someone asks for the object I check if I have already created it and return it.

But that's the Singleton pattern! I don't see how you avoided it.

I am not sure if I should stick this into the factory but this seems to violate Single Responsibility Principle.

Your object is responsible to hold the configuration. According to SRP it should also expose a method refresh() to refresh the configuration, that's still part of its responsability. But you probably don't want it to access the database. Wat you could do is then something like

class Configuration
{
   static Configuration getConfiguration()
   {
       // factory method to get the config -- kind of singleton
       // calls the DAO somewhere, e.g. configDao.getConfig();
   }

   void refresh()
   {
       // calls the DAO and refresh itself
       // configDao.refresh( this );
   }
}

class PeriodicThread
{
    Configuration.getConfiguration().refresh();
}

There is one and only one config that is maintained up-to-date periodically. I wouldn't mind with such a design.

If you use a DI framework that manage the "singletonicity" (uniqueness is a better word) of the configuration, method getConfiguration is not necessary and get away. The configuration is injected whenever needed.

ewernli
I will probably go the DI framework at a later stage. WRT avoiding the Singleton pattern I have avoided it. I have implemented as outlined in the Google test blog @ http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/. I do not have some global state that I need to ask for instances of things. Instead it is all setup right at the beginning and injected into all the classes.
uriDium