locked
Factory pattern based on a collection of business objects RRS feed

  • Question

  •  

    today i have a simple two class business object used to create a collection of preferernce objects  There is a preference class which defines a name/value pair used by the developer to store any number of preferences for a developers application.  The second is a PreferenceCollection class which implements DictionaryBase.  User creates a new PreferenceCollection object, adds individual preference objects to the collection which is persisted to a back end database.  In addition the dev can pass in a few keys which retrieves back a collection of Preferences as a PreferenceCollection.

     

    From the developers viewpoint it's a very simple object to use today; however, i'm looking to abstract out the creation of these objects via a Factory Pattern to keep things consistant with the rest of our assemblies.  Of all the exmamples i've seen on the web i've not found an example factory pattern which abstracts a custom collection behind the scenes. 

     

    If you have any experience with factory returning collections, psuedocode or examples please forward.  Thanks!

     

     

    Tuesday, February 5, 2008 8:51 PM

Answers

  • Hi,

     

    Can I first ask what you're expecting to get out of using a factory pattern to return you a collection?

     

    The idea behind the factory is to return objects through an interface for different creator objects.

     

    For the pattern to be useful, the objects that you return would need to be varied, but all implementing the same interface.

     

    If you expect that there will be other variations on your collection, then you could probably do something along the lines of:

     

    Creator collectionCreator = new PreferenceCollectionCreator();

     

    IPreferenceCollection collection = collectionCreator.Create();

     

    where

     

    PreferenceCollectionCreator is derived from a Creator base class that defines an abstract method Create()

     

    You can then create other Creator objects, and use those to construct other different types of your IPreferenceCollection interface.

     

    If this object is only ever likely to be one type of IPreferenceCollection object, you need to question whether using the factory is useful to you, or is over-engineering for the sake of it.

     

    I hope this helps to get you started,

     

    Martin Platt.

     

     

    Wednesday, February 6, 2008 3:15 AM

All replies

  • Hi,

     

    Can I first ask what you're expecting to get out of using a factory pattern to return you a collection?

     

    The idea behind the factory is to return objects through an interface for different creator objects.

     

    For the pattern to be useful, the objects that you return would need to be varied, but all implementing the same interface.

     

    If you expect that there will be other variations on your collection, then you could probably do something along the lines of:

     

    Creator collectionCreator = new PreferenceCollectionCreator();

     

    IPreferenceCollection collection = collectionCreator.Create();

     

    where

     

    PreferenceCollectionCreator is derived from a Creator base class that defines an abstract method Create()

     

    You can then create other Creator objects, and use those to construct other different types of your IPreferenceCollection interface.

     

    If this object is only ever likely to be one type of IPreferenceCollection object, you need to question whether using the factory is useful to you, or is over-engineering for the sake of it.

     

    I hope this helps to get you started,

     

    Martin Platt.

     

     

    Wednesday, February 6, 2008 3:15 AM
  • Maybe you are thinking more of a builder to create your collection for you?

     

    Thursday, February 7, 2008 7:23 AM
  • Would a builder pattern be used to create a collection?

     

    I guess it could be if the collection was made of a collection of interfaces for example, and each implementation was a composite of the collection as a whole, but that would seem like an odd implementation to me?

     

    I'd imagine a builder would be more used for an object, to create its child objects, if those child object different from one implementation of the parent object to another?

     

    It just seems that the whole concept of using a pattern for the sake of it, seems a little redundant?

     

    Perhaps you could give us a little more background information, so that we can help you out properly?

     

    Hope this helps,

     

    Martin Platt.

    Friday, February 8, 2008 12:48 AM
  • I think too much emphasis has been placed on patterns in the last few years (which is odd considering they have been out for over a decade).

     

    I think it is dangerous for new developers new to OO to pick up a pattern book and go '..oh look I might use that..' before they even think about what their program is to do in the first place.

     

    If you are a good OO programmer you will naturally start to use patterns without you even knowing you are.

     

    Getting back to your question it sounds like you need nothing more fancy than aggregation.

    Tuesday, February 12, 2008 4:47 AM