IInceptionFactory

  • dkf 2012-11-26 08:03
    It's IInstanceFactories all the way down!
  • @CodeBeater 2012-11-26 08:06
    Boss:"Can you make it simpler?"
    "Sure!"

    function createFactorySimple() {
    public IInstanceFactory getInstanceFactory();
    public IInstanceFactory getInstance();
    public IInstanceFactory getOrderFactory();
    public IInstanceFactory getGroupFactory();
    public IInstanceFactory getUserFactory();
    }
  • Ama 2012-11-26 08:13
    We need to dig deeper!

    public IInstanceFactory getInstanceOfInstance();
    public IInstanceFactory getInstanceOfInstanceOfInstanceFactory();
  • Anonymous 2012-11-26 08:19
    Not sure this will compile. Interfaces cannot have acess modifiers.
  • Honnza 2012-11-26 08:26
    This is not that bad. At least it's correctly named. We have an EntityManagerInstancesCreator backed by an EntityManagerFactory in our code base.
  • JM 2012-11-26 08:26
    Anonymous:
    Not sure this will compile. Interfaces cannot have acess modifiers.


    Yes they can. They're simply not required because public and abstract are implied. http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.4: "It is permitted, but discouraged as a matter of style, to redundantly specify the public and/or abstract modifier for a method declared in an interface."
  • 50% Opacity 2012-11-26 08:26
    But what makes the instance that makes the instance factory that makes the instance factory?! Clearly needs moar XML to solve that problem!

    Also chickens.
    And eggs.
  • MB 2012-11-26 08:37
    JM:
    Anonymous:
    Not sure this will compile. Interfaces cannot have acess modifiers.


    Yes they can. They're simply not required because public and abstract are implied. http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.4: "It is permitted, but discouraged as a matter of style, to redundantly specify the public and/or abstract modifier for a method declared in an interface."


    Java is silly, c# would not compile...
  • pkmnfrk 2012-11-26 08:38
    JM:
    Anonymous:
    Not sure this will compile. Interfaces cannot have acess modifiers.


    Yes they can. They're simply not required because public and abstract are implied. http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.4: "It is permitted, but discouraged as a matter of style, to redundantly specify the public and/or abstract modifier for a method declared in an interface."


    Unless this is C#, in which case access modifiers are forbidden on interfaces.
  • Remy Porter 2012-11-26 08:43
    While the submitter didn't specify, it's pretty clear that this isn't C#, and it is Java. I sometimes can't be sure from just the code itself, but I could tell this one was Java from across the room.
  • henke37 2012-11-26 08:55
    That's actually a real design pattern called the abstract factory pattern.

    Of course, that doesn't make it any less silly.
  • Remy Porter 2012-11-26 09:06
    That is not how you implement the Abstract Factory pattern, unless you're building a Factory to return a Factory so that you can instantiate while you instantiate.
  • LieutenantFrost 2012-11-26 09:09
    50% Opacity:
    moar XML


    This is never the answer to anything.
  • Leonardo 2012-11-26 09:13
  • Remy Porter 2012-11-26 09:21
    <answer to="everything"><is><![CDATA[xml]]></is></answer>
  • Coward 2012-11-26 09:36
    Honnza:
    This is not that bad. At least it's correctly named. We have an EntityManagerInstancesCreator backed by an EntityManagerFactory in our code base.

    I know where you work!
  • Todd Lewis 2012-11-26 09:40
    LieutenantFrost:
    50% Opacity:
    moar XML


    This is never the answer to anything.


    Q: "What is never the answer to anything?"
    A: ... Oh, never mind.
  • Rodnas 2012-11-26 09:49
    I always thought we needed to make things more difficult or at least redundant i.e.:


    function TrueOrFalse (var bool): var
    switch boolean (bool) {
    case true :
    return true;
    break;

    case false :
    return false;
    break;

    default:
    return "FileNotFound";
    break;
    }
    }


  • Cbuttius 2012-11-26 10:07
    But don't worry, the developer who wrote this had browsed through Gang Of Four's book and was able to state a few design patterns by their names, so he was CLEARLY a good designer.

    But then, in a language where everything is an object, I guess everything that creates objects as an IInstanceFactory?

    What do you do if you want to create an instance of an IInstanceFactory? I don't see an IInstanceFactoryFactory or is that the difference between getInstanceFactory and getInstance?
  • Zecc 2012-11-26 10:18
    @CodeBeater:
    Boss:"Can you make it simpler?"
    "Sure!"

    function createFactorySimple() {
    public IInstanceFactory getInstanceFactory();
    public IInstanceFactory getInstance();
    public IInstanceFactory getOrderFactory();
    public IInstanceFactory getGroupFactory();
    public IInstanceFactory getUserFactory();
    }
    Weird syntax you got there.
  • Captain Oblivious 2012-11-26 10:29
    The factory pattern is a lot of boilerplate implementing a simple functor between categories. The problem isn't the factories, or even nested factories. It's the boilerplate.

    In Haskell, the (identity) factory pattern is implemented by:

    data F a = F a

    instance Functor F where fmap f (F a) = F . f $ a

    We can create stacks of functors using functor transformers.
  • sniederb 2012-11-26 10:47
    Was it here that someone pointed out the wonderful AbstractSingletonProxyFactoryBean?
  • airdrik 2012-11-26 10:48
    Captain Oblivious:
    The factory pattern is a lot of boilerplate implementing a simple functor between categories. The problem isn't the factories, or even nested factories. It's the boilerplate.

    In Haskell, the (identity) factory pattern is implemented by:

    data F a = F a

    instance Functor F where fmap f (F a) = F . f $ a

    We can create stacks of functors using functor transformers.


    Thank you Captain Obvious!
  • Gaza Rullz 2012-11-26 10:55

  • Brendan 2012-11-26 11:14
    Captain Oblivious:
    The factory pattern is a lot of boilerplate implementing a simple functor between categories. The problem isn't the factories, or even nested factories. It's the boilerplate.

    In Haskell, the (identity) factory pattern is implemented by:

    data F a = F a

    instance Functor F where fmap f (F a) = F . f $ a

    We can create stacks of functors using functor transformers.


    TL;DR: Haskell is Perl encrypted with a "F" map!
  • Quicksilver 2012-11-26 11:25
    the real WTF is that the instance Factory is not parametrized.


    i.e.

    public Interface IInstanceFactory<K extends IInstanceFactory> {...}

    and then returning special instances of K!
  • Cbuttius 2012-11-26 11:48
    Quicksilver:
    the real WTF is that the instance Factory is not parametrized.


    i.e.

    public Interface IInstanceFactory<K extends IInstanceFactory> {...}

    and then returning special instances of K!


    could be pre-generics legacy code?
  • emaNrouY-Here 2012-11-26 11:54
    There are times when unhiding the commentary is not a good thing. It seems Gaza Rullz took care of picturizing it for everyone.
  • jlmt 2012-11-26 12:48
    Quicksilver:
    the real WTF is that the instance Factory is not parametrized.

    i.e.

    public Interface IInstanceFactory<K extends IInstanceFactory> {...}

    and then returning special instances of K!


    Special K probably explains a lot more of this than you think.
  • Evan 2012-11-26 14:24
    CommentFactory.getCommentFactory()
  • Ben 2012-11-26 18:44
    Unicorns! Unicorns and rainbows!

    o_o

    Captcha: suscipit
  • Norman Diamond 2012-11-26 19:41
    Todd Lewis:
    LieutenantFrost:
    This is never the answer to anything.
    Q: "What is never the answer to anything?"
    A: ... Oh, never mind.
    Sounds like Smullyan's in Jeopardy.

    A: "What is never the answer to anything?"
    Q: "What is never the answer to anything?"
  • Captain Oblivious 2012-11-26 20:56
    Brendan:
    Captain Oblivious:
    The factory pattern is a lot of boilerplate implementing a simple functor between categories. The problem isn't the factories, or even nested factories. It's the boilerplate.

    In Haskell, the (identity) factory pattern is implemented by:

    data F a = F a

    instance Functor F where fmap f (F a) = F . f $ a

    We can create stacks of functors using functor transformers.


    TL;DR: Haskell is Perl encrypted with a "F" map!


    If that's too much boilerplate, you can even do:

    data F a = F a deriving (Functor)

    Or are you whining about the (.) and ($)? The latter is just function application, and the former is function composition.
  • Geoff 2012-11-27 01:02
    Todd Lewis:
    LieutenantFrost:
    50% Opacity:
    moar XML


    This is never the answer to anything.


    Q: "What is never the answer to anything?"
    A: ... Oh, never mind.


    +10!
  • Geoff 2012-11-27 01:07
    Cbuttius:
    But don't worry, the developer who wrote this had browsed through Gang Of Four's book and was able to state a few design patterns by their names, so he was CLEARLY a good designer.

    But then, in a language where everything is an object, I guess everything that creates objects as an IInstanceFactory?

    What do you do if you want to create an instance of an IInstanceFactory? I don't see an IInstanceFactoryFactory or is that the difference between getInstanceFactory and getInstance?


    Which is precisely why I always think the usual factory pattern is broken. Factories should not create instances of themselves - when do you ever go to a real factory and say "Build me another factory like this one!"? Instead, the factory should let you get an instance of a manager who can help you build specialised objects.
  • AlephZero 2012-11-27 03:10
    This is not that bad. At least it's correctly named. We have an EntityManagerInstancesCreator backed by an EntityManagerFactory in our code base.


    Well, it could go worse, you could have had an abstract EntityManagerFactoryInstanceCreatorFactoryBuilder

    captcha: nobis. Bad usage of the factory pattern is a big nobis-nobis
  • @CodeBeater 2012-11-27 03:43
    I don't understand anything of real programming languages like Java or C#, just crappy php
  • @CodeBeater 2012-11-27 03:44
    Zecc:
    @CodeBeater:
    Boss:"Can you make it simpler?"
    "Sure!"

    function createFactorySimple() {
    public IInstanceFactory getInstanceFactory();
    public IInstanceFactory getInstance();
    public IInstanceFactory getOrderFactory();
    public IInstanceFactory getGroupFactory();
    public IInstanceFactory getUserFactory();
    }
    Weird syntax you got there.


    I don't understand anything if real programming languages such as Java or C#, just crappy php
  • Cbuttius 2012-11-27 04:38
    Actually in my Dependency Injection library (which is implemented in C++ but could also be implemented in another language) you have Builders and Factories.

    You normally get a BuilderFactoryImpl<BuilderX> which derives from BuilderFactory<BuilderX> and creates you a BuilderX which derives from BuilderT<X> and creates you an X or something that derives from X.

    This is all done at initiation time, so if you want something that will create objects later your X would be a Factory<Y>. So you can have a factory to a builder of factories.

    If you think that is complicated:

    1. BuilderFactoryImpl<T> is actually the only implemented version of BuilderFactory<T>. There isn't actually that much of a need to use a hierarchy here.

    2. The difference between a Builder and a Factory is that a Builder only builds a single object, a Factory can build more than one object.

    3. BuilderFactory instances are often re-used, when you want more than one instance of a class (each of which needs its own builder)

    4. Different Builder implementations normally build different derived classes, but you can have more than one that creates the same class but in a different way (e.g. uses different parameters)

    Essentially, and this is the key point you need to know about the AbstractFactory pattern:

    The purpose of this pattern is to enable you to create objects from your source code, without know at this point in your code the actual class that you are going to create. You only know the base class from which this class derives.

    The Factory Pattern is often the best pattern to use for message handling, whereby you read the "header" then decide what type of message you have and get it to "process".

    Quite often you will have some kind of table (key to factory).
  • Jasper 2012-11-27 05:21
    Oh, but this is nothing strange, it's just a factory factory! Not the first time I see this.
  • Nagesh 2012-11-27 09:44
    Captain Oblivious:
    Or are you whining about the (.) and ($)? The latter is just function application, and the former is function composition.

    I think the point was that writing "F(f a)" as "F . f $ a" must have been the last desperate act of a former Perl programmer with a bad case of obfuscation withdrawal.
  • Brendan 2012-11-27 10:19
    Nagesh:
    Captain Oblivious:
    Or are you whining about the (.) and ($)? The latter is just function application, and the former is function composition.

    I think the point was that writing "F(f a)" as "F . f $ a" must have been the last desperate act of a former Perl programmer with a bad case of obfuscation withdrawal.


    Exactly.

    I still remember when language researchers strived to make their languages look as natural as possible (when "ideal" was considered to be a compiler that understood plain English sentences). At the current rate of "acceleration away from ideal" people will be switching to punch cards soon, just to squeeze out that last remaining drop of "incomprehensible".
  • Norman Diamond 2012-11-27 18:06
    Refactoryfactorying prime numbers is hard.
  • anon 2012-11-27 18:20
    Brendan:
    Nagesh:
    Captain Oblivious:
    Or are you whining about the (.) and ($)? The latter is just function application, and the former is function composition.

    I think the point was that writing "F(f a)" as "F . f $ a" must have been the last desperate act of a former Perl programmer with a bad case of obfuscation withdrawal.


    Exactly.

    I still remember when language researchers strived to make their languages look as natural as possible (when "ideal" was considered to be a compiler that understood plain English sentences). At the current rate of "acceleration away from ideal" people will be switching to punch cards soon, just to squeeze out that last remaining drop of "incomprehensible".

    I think COBOL kind of proved that this was a bad goal. Programming just isn't like human conversation; making rigorous statements with English-like syntax is just frustrating.

    (Apple went back to that well and gave us HyperTalk and AppleScript just to really drive the point home!)
  • josh 2012-11-27 18:52
    public is a legitimate access modifier for interfaces.
  • Paul 2012-11-28 08:04
    I always use 'public interface' to remind myself that the interface *will* be public. This needn't have been the case. It would have been nice if Java had supported interfaces that were package local - i.e. just 'interface'.

    This would have allowed libraries to provide multiple implementations of an interface without exposing the interface to random external implementations. (Aside: No serious Java code-base is complete without its own buggy, undocumented, contact-violating implementation of List or Map. And don't get me started on bad implementations of Iterator!)

    It would also have allowed the interface to evolve (in some ways e.g. adding methods) between releases. Since the only implementations would be provided in the same package, these could be updated in line with the interface. When an interface became stable -and- it became useful to allow external implementations, then the interface could have become a 'public interface'.
  • Nagesh 2012-11-28 09:44
    Brendan:
    Nagesh:
    I think the point was that writing "F(f a)" as "F . f $ a" must have been the last desperate act of a former Perl programmer with a bad case of obfuscation withdrawal.

    Exactly.

    I still remember when language researchers strived to make their languages look as natural as possible

    You can't blame Haskell's designers here, though, because
    F(f a)
    is valid Haskell syntax that does exactly what we (presumably) want. The obfuscated version
    F . f $ a
    was introduced by Captain Oblivious.
  • Nagesh 2012-11-28 09:53
    Paul:
    I always use 'public interface' to remind myself that the interface *will* be public. This needn't have been the case. It would have been nice if Java had supported interfaces that were package local - i.e. just 'interface'.
    But it does! Interfaces can have the same access specifiers as classes can, and these specifiers do control where the interface is visible.

    What Java doesn't support (for reasons I haven't entirely grasped) is non-public members of interfaces.
  • Neil 2012-11-28 11:44
    Evan:
    CommentFactory.getCommentFactory()
    ReplyFactory.getReplyFactory().getReplyInstance().getReply()
  • Bill C. 2012-11-28 19:03
    My pubic interfaces weren't supposed to be public.
  • ShatteredArm 2012-11-29 13:06
    TDWTF: Where factory.getInstance().getInstance().getInstanceFactory().getInstance().getInstanceFactory().getOrderFactory().getInstance().getInstanceFactory() compiles.
  • Factory Master 2012-11-30 03:29
    Yo dawg, we heard you like factories so we built a factory to return a factory so you can instantiate while you instantiate
  • Factory Master 2012-11-30 03:31
    Oh, someone fristed me on the yo dawg.

    captcha: ludus
  • Honnza 2012-11-30 06:19
    ShatteredArm:
    TDWTF: Where factory.getInstance().getInstance().getInstanceFactory().getInstance().getInstanceFactory().getOrderFactory().getInstance().getInstanceFactory() compiles.


    It is valid JavaScript (and TypeScript, which compiles to JavaScript).

    The fact that it most likely throws a TypeError is irrelevant. It still compiles.
  • ab 2013-01-02 17:06
    Zecc:
    @CodeBeater:
    Boss:"Can you make it simpler?"
    "Sure!"

    function createFactorySimple() {
    public IInstanceFactory getInstanceFactory();
    public IInstanceFactory getInstance();
    public IInstanceFactory getOrderFactory();
    public IInstanceFactory getGroupFactory();
    public IInstanceFactory getUserFactory();
    }
    Weird syntax you got there.

    I don't know Java, so I'm not sure what "Boss:" does, but I assume it's a valid control statement that Python just doesn't have.

    Anyway, according to PEP 8, you should never inline code after the colon; put the rest of the block on a new line, with proper indentation. Also, docstrings should be in triple-quotes, and not rely on string concatenation. So:

    Boss:
    """Can you make it simpler?
    Sure!"""
    # rest of your code goes here
  • SmeckleTickle 2013-06-24 21:52
    "The Factory pattern is an excellent way to solve a variety of programming problems using an object-oriented language."

    No. No, it is not.