The Daily WTF: Curious Perversions in Information Technology

dkf · 2012-11-26 Reply Admin

It's IInstanceFactories all the way down!

2012-11-26 Reply Admin

Boss:"Can you make it simpler?" "Sure!"

function createFactorySimple() { public IInstanceFactory getInstanceFactory();
public IInstanceFactory getInstance();
public IInstanceFactory getOrderFactory();
public IInstanceFactory getGroupFactory();
public IInstanceFactory getUserFactory();
}

2012-11-26 Reply Admin

We need to dig deeper!

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

2012-11-26 Reply Admin

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

2012-11-26 Reply Admin

This is not that bad. At least it's correctly named. We have an EntityManagerInstancesCreator backed by an EntityManagerFactory in our code base.

2012-11-26 Reply Admin

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

2012-11-26 Reply Admin

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.

2012-11-26 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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.

2012-11-26 Reply Admin

50% Opacity:
moar XML

This is never the answer to anything.

2012-11-26 Reply Admin

[image]

Remy Porter · 2012-11-26 Reply Admin

2012-11-26 Reply Admin

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!

2012-11-26 Reply Admin

LieutenantFrost:
50% Opacity:
moar XML

This is never the answer to anything.

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

2012-11-26 Reply Admin

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 Reply Admin

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 Reply Admin

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

2012-11-26 Reply Admin

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 Reply Admin

Was it here that someone pointed out the wonderful AbstractSingletonProxyFactoryBean?

2012-11-26 Reply Admin

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!

2012-11-26 Reply Admin

[image]

2012-11-26 Reply Admin

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!

2012-11-26 Reply Admin

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 Reply Admin

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?

2012-11-26 Reply Admin

There are times when unhiding the commentary is not a good thing. It seems Gaza Rullz took care of picturizing it for everyone.

2012-11-26 Reply Admin

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.

2012-11-26 Reply Admin

CommentFactory.getCommentFactory()

2012-11-26 Reply Admin

Unicorns! Unicorns and rainbows!

o_o

Captcha: suscipit

2012-11-26 Reply Admin

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?"

2012-11-26 Reply Admin

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.

2012-11-27 Reply Admin

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!

2012-11-27 Reply Admin

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.

2012-11-27 Reply Admin

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

2012-11-27 Reply Admin

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

2012-11-27 Reply Admin

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 Reply Admin

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:

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.
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.
BuilderFactory instances are often re-used, when you want more than one instance of a class (each of which needs its own builder)
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).

2012-11-27 Reply Admin

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

2012-11-27 Reply Admin

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.

2012-11-27 Reply Admin

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

2012-11-27 Reply Admin

Refactoryfactorying prime numbers is hard.

2012-11-27 Reply Admin

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

2012-11-27 Reply Admin

public is a legitimate access modifier for interfaces.

2012-11-28 Reply Admin

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

2012-11-28 Reply Admin

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.

2012-11-28 Reply Admin

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.

2012-11-28 Reply Admin

Evan:
CommentFactory.getCommentFactory()

ReplyFactory.getReplyFactory().getReplyInstance().getReply()

2012-11-28 Reply Admin

My pubic interfaces weren't supposed to be public.

IInceptionFactory

Leave a comment on “IInceptionFactory”