Comment On IInceptionFactory

It's IInstanceFactories all the way down!

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

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

We need to dig deeper!

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

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

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

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

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.

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

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.

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.

That's actually a real design pattern called the abstract factory pattern.

Of course, that doesn't make it any less silly.

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.

50% Opacity:

moar XML

This is never the answer to anything.

<answer to="everything"><is><![CDATA[xml]]></is></answer>

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!

LieutenantFrost:

50% Opacity:

moar XML

This is never the answer to anything.

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

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;

   }

}

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?

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

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.

Was it here that someone pointed out the wonderful AbstractSingletonProxyFactoryBean?

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!

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!

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!

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?

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

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.

CommentFactory.getCommentFactory()

Unicorns! Unicorns and rainbows!

o_o

Captcha: suscipit

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

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.

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!

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.

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

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

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

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

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

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.

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

Refactoryfactorying prime numbers is hard.

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

public is a legitimate access modifier for interfaces.

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

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.

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.

Evan:

CommentFactory.getCommentFactory()

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

My pubic interfaces weren't supposed to be public.