Comment On IInceptionFactory

The Factory pattern is an excellent way to solve a variety of programming problems using an object-oriented language. It’s a simple pattern, but for some developers, not quite simple enough. Den found this interface : [expand full text]
« PrevPage 1 | Page 2Next »

Re: IInceptionFactory

2012-11-26 08:03 • by dkf
It's IInstanceFactories all the way down!

Re: IInceptionFactory

2012-11-26 08:06 • by @CodeBeater (unregistered)
Boss:"Can you make it simpler?"
"Sure!"

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

Re: IInceptionFactory

2012-11-26 08:13 • by Ama (unregistered)
We need to dig deeper!

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

Re: IInceptionFactory

2012-11-26 08:19 • by Anonymous (unregistered)
Not sure this will compile. Interfaces cannot have acess modifiers.

Re: IInceptionFactory

2012-11-26 08:26 • by Honnza (unregistered)
This is not that bad. At least it's correctly named. We have an EntityManagerInstancesCreator backed by an EntityManagerFactory in our code base.

Re: IInceptionFactory

2012-11-26 08:26 • by JM (unregistered)
395520 in reply to 395518
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."

Re: IInceptionFactory

2012-11-26 08:26 • by 50% Opacity (unregistered)
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.

Re: IInceptionFactory

2012-11-26 08:37 • by MB (unregistered)
395522 in reply to 395520
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...

Re: IInceptionFactory

2012-11-26 08:38 • by pkmnfrk
395523 in reply to 395520
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.

Re: IInceptionFactory

2012-11-26 08:43 • by Remy Porter
395524 in reply to 395523
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.

Re: IInceptionFactory

2012-11-26 08:55 • by henke37
That's actually a real design pattern called the abstract factory pattern.

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

Re: IInceptionFactory

2012-11-26 09:06 • by Remy Porter
395526 in reply to 395525
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.

Re: IInceptionFactory

2012-11-26 09:09 • by LieutenantFrost (unregistered)
395527 in reply to 395521
50% Opacity:
moar XML


This is never the answer to anything.

Deeper

2012-11-26 09:13 • by Leonardo (unregistered)

Re: IInceptionFactory

2012-11-26 09:21 • by Remy Porter
395529 in reply to 395527
<answer to="everything"><is><![CDATA[xml]]></is></answer>

Re: IInceptionFactory

2012-11-26 09:36 • by Coward (unregistered)
395530 in reply to 395519
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!

Re: IInceptionFactory

2012-11-26 09:40 • by Todd Lewis (unregistered)
395531 in reply to 395527
LieutenantFrost:
50% Opacity:
moar XML


This is never the answer to anything.


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

Re: IInceptionFactory

2012-11-26 09:49 • by Rodnas (unregistered)
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;
}
}


Re: IInceptionFactory

2012-11-26 10:07 • by 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?

Re: IInceptionFactory

2012-11-26 10:18 • by Zecc
395538 in reply to 395516
@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.

Re: IInceptionFactory

2012-11-26 10:29 • by Captain Oblivious (unregistered)
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.

Re: IInceptionFactory

2012-11-26 10:47 • by sniederb
Was it here that someone pointed out the wonderful AbstractSingletonProxyFactoryBean?

Re: IInceptionFactory

2012-11-26 10:48 • by airdrik (unregistered)
395541 in reply to 395539
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!

Re: IInceptionFactory

2012-11-26 10:55 • by Gaza Rullz (unregistered)

Re: IInceptionFactory

2012-11-26 11:14 • by Brendan (unregistered)
395543 in reply to 395539
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!

Re: IInceptionFactory

2012-11-26 11:25 • by Quicksilver (unregistered)
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!

Re: IInceptionFactory

2012-11-26 11:48 • by Cbuttius
395545 in reply to 395544
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?

Re: IInceptionFactory

2012-11-26 11:54 • by emaNrouY-Here (unregistered)
There are times when unhiding the commentary is not a good thing. It seems Gaza Rullz took care of picturizing it for everyone.

Re: IInceptionFactory

2012-11-26 12:48 • by jlmt (unregistered)
395549 in reply to 395544
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.

Re: IInceptionFactory

2012-11-26 14:24 • by Evan (unregistered)
CommentFactory.getCommentFactory()

Re: IInceptionFactory

2012-11-26 18:44 • by Ben (unregistered)
Unicorns! Unicorns and rainbows!

o_o

Captcha: suscipit

Re: IInceptionFactory

2012-11-26 19:41 • by Norman Diamond (unregistered)
395560 in reply to 395531
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?"

Re: IInceptionFactory

2012-11-26 20:56 • by Captain Oblivious (unregistered)
395561 in reply to 395543
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.

Re: IInceptionFactory

2012-11-27 01:02 • by Geoff (unregistered)
395562 in reply to 395531
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!

Re: IInceptionFactory

2012-11-27 01:07 • by Geoff (unregistered)
395563 in reply to 395536
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.

Re: IInceptionFactory

2012-11-27 03:10 • by AlephZero (unregistered)
395564 in reply to 395519
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

Re: IInceptionFactory

2012-11-27 03:43 • by @CodeBeater (unregistered)
395565 in reply to 395538
I don't understand anything of real programming languages like Java or C#, just crappy php

Re: IInceptionFactory

2012-11-27 03:44 • by @CodeBeater (unregistered)
395566 in reply to 395538
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

Re: IInceptionFactory

2012-11-27 04:38 • by Cbuttius
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).

Re: IInceptionFactory

2012-11-27 05:21 • by Jasper (unregistered)
Oh, but this is nothing strange, it's just a factory factory! Not the first time I see this.

Re: IInceptionFactory

2012-11-27 09:44 • by Nagesh (unregistered)
395589 in reply to 395561
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.

Re: IInceptionFactory

2012-11-27 10:19 • by Brendan (unregistered)
395593 in reply to 395589
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".

Re: IInceptionFactory

2012-11-27 18:06 • by Norman Diamond (unregistered)
Refactoryfactorying prime numbers is hard.

Re: IInceptionFactory

2012-11-27 18:20 • by anon (unregistered)
395646 in reply to 395593
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!)

Re: IInceptionFactory

2012-11-27 18:52 • by josh (unregistered)
395649 in reply to 395518
public is a legitimate access modifier for interfaces.

Re: IInceptionFactory

2012-11-28 08:04 • by Paul (unregistered)
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'.

Re: IInceptionFactory

2012-11-28 09:44 • by Nagesh (unregistered)
395693 in reply to 395593
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.

Re: IInceptionFactory

2012-11-28 09:53 • by Nagesh (unregistered)
395697 in reply to 395665
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.

Re: IInceptionFactory

2012-11-28 11:44 • by Neil (unregistered)
395714 in reply to 395553
Evan:
CommentFactory.getCommentFactory()
ReplyFactory.getReplyFactory().getReplyInstance().getReply()

Re: IInceptionFactory

2012-11-28 19:03 • by Bill C. (unregistered)
My pubic interfaces weren't supposed to be public.
« PrevPage 1 | Page 2Next »

Add Comment