public IInstanceFactory getInstanceOfInstance();
public IInstanceFactory getInstanceOfInstanceOfInstanceFactory();

Anonymous2012-11-26 08:19

Not sure this will compile. Interfaces cannot have acess modifiers.

Honnza2012-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.

JM2012-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% Opacity2012-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.

MB2012-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...

pkmnfrk2012-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 Porter2012-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.

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 Rullz2012-11-26 10:55

Brendan2012-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!

Quicksilver2012-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!

Cbuttius2012-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-Here2012-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.

jlmt2012-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.

Evan2012-11-26 14:24

CommentFactory.getCommentFactory()

Ben2012-11-26 18:44

Unicorns! Unicorns and rainbows!

o_o

Captcha: suscipit

Norman Diamond2012-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 Oblivious2012-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.

Geoff2012-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!

Geoff2012-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.

AlephZero2012-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

@CodeBeater2012-11-27 03:43

I don't understand anything of real programming languages like Java or C#, just crappy php

I don't understand anything if real programming languages such as Java or C#, just crappy php

Cbuttius2012-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).

Jasper2012-11-27 05:21

Oh, but this is nothing strange, it's just a factory factory! Not the first time I see this.

Nagesh2012-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.

Brendan2012-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 Diamond2012-11-27 18:06

Refactoryfactorying prime numbers is hard.

anon2012-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!)

josh2012-11-27 18:52

public is a legitimate access modifier for interfaces.

Paul2012-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'.

Nagesh2012-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.

Nagesh2012-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.

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: