ObjectFactory



  • There are lots of ways of implementing factories. The powers-that-be around here have chosen the following paradigm:

     

    public class ObjectFactory {
    public static X createX() { return new X(); }
    public static Y createY() { return new Y(); }
    ...
    }

    There are lots of ways to do this, but this is tolerable, and very easy to understand.

    Then I discovered that instead of a single static/singleton object that does this for the entire application, there is at least one of these in every project. In numerous cases, there is one in every package; each one just implementing enough for the local needs. In several cases, different ObjectFactory's will create different versions of a class X (e.g.: projects A and B both have their own implementation of X). This renders auto-complete utterly useless.

    Think about this: you're in some IDE. you type: "ObjectFactory." and in a second, only the local one pops up. What if you want to create something you can only create from another ObjectFactory? What if you want to create an instance of X, but depending upon which ObjectFactory you use, you get a different implementation of X?

    Why, why, why TF would anyone ever do this?!

     



  • You obviously want this because... I don't know. Don't have a valid reason. It's only harder than new X() so just, why?


  • ♿ (Parody)

    @snoofle said:

    Why, why, why TF would anyone ever do this?!

    Sounds like cargo cult pattern programming.


  • 🚽 Regular

    Someone heard about the wonderful world of factories and decided to think "Instead of using singletons, you should use factories in your code" is all the knowledge one needs to use a factory pattern... and took this to the absurd level and declared that not even factories should ever be singletons.

    I suggest that, for entertainment purposes, you recommend the programmer use Inversion of Control, Injection Containers, and other concepts and see just how far he's going to divert from a "sane" approach to those patterns.



  • @RHuckster said:

    I suggest that, for entertainment purposes, you recommend the programmer use Inversion of Control, Injection Containers, and other concepts and see just how far he's going to divert from a "sane" approach to those patterns.

     

    So, in other words, go farming for WTFs!

     



  • @boomzilla said:

    @snoofle said:
    Why, why, why TF would anyone ever do this?!

    Sounds like cargo cult pattern programming.

     Probably, but not definately. There are many good reasons for restricting the types of objects that may be created (or accessed) within a given context (such as a package). Having a facotry which only exposes the "approved" types is a fairly simple way to accomplish this. You simply have to verify that teh one file (the factory) contains only approved items, and that there are no calls to "new" anywhere.



  • Eclipse has a "restricted packages" feature which will raise warnings/errors if you use packages you mark as "restricted"...



  • @TheCPUWizard said:

    @boomzilla said:

    @snoofle said:
    Why, why, why TF would anyone ever do this?!

    Sounds like cargo cult pattern programming.

     Probably, but not definately. There are many good reasons for restricting the types of objects that may be created (or accessed) within a given context (such as a package). Having a facotry which only exposes the "approved" types is a fairly simple way to accomplish this. You simply have to verify that teh one file (the factory) contains only approved items, and that there are no calls to "new" anywhere.

    How is that easier than simply getting the access modifiers on the constructors correct? Factories are usually used to centralize the logic of choosing which implementation of an interface to create, not as an alternative to "public".



  • @Jaime said:

    @TheCPUWizard said:

    @boomzilla said:

    @snoofle said:
    Why, why, why TF would anyone ever do this?!

    Sounds like cargo cult pattern programming.

     Probably, but not definately. There are many good reasons for restricting the types of objects that may be created (or accessed) within a given context (such as a package). Having a facotry which only exposes the "approved" types is a fairly simple way to accomplish this. You simply have to verify that teh one file (the factory) contains only approved items, and that there are no calls to "new" anywhere.

    How is that easier than simply getting the access modifiers on the constructors correct? Factories are usually used to centralize the logic of choosing which implementation of an interface to create, not as an alternative to "public".

    Not referring to access specifiers. Consider you have namespaces "A" thru "Z"... Now youant to ensure that "J" can only reference "P","Q", and "E"... "L" can only reference "P", "A" and "S"....and so on to any arbitrary level of complexity. While this example seems convoluted, the real-world use cases are quite common. Just look at the actual references between namespaces in any large project, then consider how you would allow those relationships but prohibit any new relationships from being created....


Log in to reply