This discussion is archived
5 Replies Latest reply: Sep 7, 2010 3:52 PM by 796367 RSS

Coding to Interfaces - Concrete Factory Pattern

807580 Newbie
Currently Being Moderated
An issue comes up when coding to interfaces rather than implementing classes and using the factory pattern. In this particular case I am coding for java.util.List, rather than java.util.Vector or java.util.ArrayList, and all works well except when it comes to my concrete factory classes. Obviously, the factory provides an implementation of List. What is a graceful way to allow the developer to choose the List implementation? My current handling:

Using two methods: createObject and createObjectThreadSafe

Using two factories: ObjectFactory and ObjectFactoryThreadSafe

Allowing a parameter to be passed in that would dictate the implementation.



Does anyone have a better, more graceful way of handling for this?


Thank you!
  • 1. Re: Coding to Interfaces - Concrete Factory Pattern
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    rocky.madden wrote:
    An issue comes up when coding to interfaces rather than implementing classes and using the factory pattern. In this particular case I am coding for java.util.List, rather than java.util.Vector or java.util.ArrayList, and all works well except when it comes to my concrete factory classes. Obviously, the factory provides an implementation of List. What is a graceful way to allow the developer to choose the List implementation? My current handling:
    A factory that does nothing but create java collections would of course be overkill.

    From the Factory Pattern in the GoF book: "+...but let subclasses decide which class to instantiate."+

    Thus the user of the factory does not "choose" the implementation.
  • 2. Re: Coding to Interfaces - Concrete Factory Pattern
    796367 Explorer
    Currently Being Moderated
    Does anyone have a better, more graceful way of handling for this?
    Depends on what you call graceful. I just came stumbling out of the pub when I slipped on a greasy rag and didn't spill one single drop of my bloodyMary. Now that's graceful.
  • 3. Re: Coding to Interfaces - Concrete Factory Pattern
    807580 Newbie
    Currently Being Moderated
    Agreed.

    More elaboration: One of the attributes of the object being created is a collection of objects. It's a SQL parser, it's creating a "SelectClause" object to place the "SelectQuery" object. The SelectClause object has an List of "Column" objects. I suppose it could be implemented as a simple array or a set. Thanks for the help.
  • 4. Re: Coding to Interfaces - Concrete Factory Pattern
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    rocky.madden wrote:
    More elaboration: One of the attributes of the object being created is a collection of objects. It's a SQL parser, it's creating a "SelectClause" object to place the "SelectQuery" object. The SelectClause object has an List of "Column" objects. I suppose it could be implemented as a simple array or a set.
    That doesn't seem to help me. I can't imagine why a factory is appropriate for that.
    Also you wouldn't create the container after parsing the clause. Instead you would create the container first then parse the clause.
  • 5. iBATIS [was: ... Concrete Factory Pattern]
    782681 Newbie
    Currently Being Moderated
    SQL, select, query, columns hm. Factory-shmactory, patterns-shmatterns. Did you consider iBATIS?

    +// "...iBATIS... automates the mapping between SQL databases and... POJOs... The result is a significant reduction in the amount of code that a developer needs to access a relational database using lower level APIs like JDBC..."+