Factory classes

Can somebody explain what are factory classes good for? As in, "why all this shit"? I have the impression factory classes are yet another suit in the Emperor's wardrobe. To me, they always looked like some bored programmer who needs to keep his job and hates the KISS principle decided to make our lives worse.

Generally speaking, they are useful in cases where you want more flexibility in creating instances than you get with the language's built-in construction operations (i.e. "new").

E.g. if you want a function that creates different subclasses of a  common parent depending upon its arguments, or if you want to easily create lots of very similar instances of a very generalised class.

They're an attempt to improve performance by avoiding instantiating new objects all the time. Rather than let the programmer keep one object and constantly change it all the time (which would defeat the point of OO as an abstraction) you hide it behind a factory class. So when you call fooFactory.newFoo() you're not actually getting a new instance, it's modifying an old one for you.

Yeah it's a lot of extra work. Which sucks. If the compiler would do it automagically that would rock. I've actually been thinking about this recently: how about a language in which all objects are immutable and the compiler created factory classes behind the scenes for optimisation? I think this could be a useful way to merge OOP and FP.

Also see flyweight programming.

>>2
Notice how you said "a function". It sucks to have a fixed paradigm language.

>>3
Oh, yeah, immutable objects. A disturbing and illogical idea IMO. I write on my notepad, not destroy it and create a new one. I change my string to uppercase, not waste it and create a new one. Even for an abstraction it's no good. Then you're forced to do a lot of object juggling, which is inefficient; rely even more on the garbage collector, which may be inefficient and may fragment and/or waste your memory; have to create and/or use even more classes and methods, which affects your productivity; and makes your code even more insane and hard to maintain.

This all looks to me like another blOOatware factory, no pun intended.

To sum things up: There is a lot of confusion about what a factory class is, and most uses of them suck. In fact, except for the Abstract Factory pattern, I can't think of any excuse to have a separate class simply for instantiating objects.

Then you're forced to do a lot of object juggling, which is inefficient; rely even more on the garbage collector, which may be inefficient and may fragment and/or waste your memory
Wrong, as I explained this is why factories exist; to prevent instantiating new objects unneccessarily.

have to create and/or use even more classes and methods, which affects your productivity; and makes your code even more insane and hard to maintain.
True. Performance hacks always make you pay for speeding the program by slowing down the programmer. Rarely worth it these days. Compilers should be responsible for any and all optimization, making the programmer do it by hand is Bad and Wrong.

>>6
Then you're forced to do a lot of object juggling, which is inefficient; rely even more on the garbage
By "you" I meant "the computer".

Compilers should be responsible for any and all optimization, making the programmer do it by hand is Bad and Wrong.

And this is why Every OS Sucks. Let's All Capitalize Words We Read In The Jargon File! LUSERS!

>>8
This is a more realistic depiction of a meaningful contribution to a discussion than the tearful depictions often found on usenet.

A real case that I have used factories for:

I have made a game engine that has map graphics and "things" that live within the map. Each thing, of course, is its own object instance, and probably from different classes. That's how it is during gameplay, that is. If I'm in a map editor, however, what I want is to start from a "pre-thing" that can be manipulated in a regular and predictable way, rather than having a lot of special cases and wastefully storing more info than necessary within the map.

Thus the factory concept naturally applies. I start from the standpoint of the predictable pre-object instances, then convert them one by one at runtime. This is a case where you really want additional data abstraction so as to ease the flow of the code handling it.

In a lot of cases zero abstractions(and therefore no new classes) are needed; one can adequately and concisely deal with lots of data kept in primitive types. this is my main beef with Java, because it forces on some potentially unnecessary abstraction.

>>10

Sounds like you could use some decorators, too, if you aren't already.

>>11

Confession: I don't use decorators, not because they aren't useful, but because they scare me and boggle my brain. I'm just an amateur, really, and I learn programming concepts a little bit at a time as they become something I *observe* happening within my own code.

In the particular case of my current project, they don't actually seem to be necessary here because what I'm actually doing is a very simple mapping of my properties between two classes, the "storage" one and the "living" one. Everything is very predictable in that environment. I was, earlier, doing a project where it was going from "storage" to "anything" which I stopped before I had very much in the "anything" part. Had I added a lot I think I can see where the decorator pattern might have become useful; decorating would have greatly decreased the amount of duplicate code by letting me say something like "do the standard init for this type of object, and then also do this other thing which is more special-case," but I hadn't gotten there; I was using simple inheritance mostly and letting stuff be rewritten fairly frequently.

>>12

Ah, that's cool.  :)  We all learn what we need to know when we need to know it, there's way too much out there to try to take it in all at once.  And, of course, you know what you're working on a heckuva' lot better than I do.

The thing that always thrills me is when I'm designing along, happy as can be, then read about a pattern and think, "Hey!  I have that!  But I made this mistake and that mistake..." so I can go back and fix a few subtle abstraction errors that slipped by my own homegrown solution.  I really think that that's the big value in a book like the GoF.  Patterns come naturally when you're considering a solution, and the book points out a couple of the common and easy-to-make errors so that I can recognize my pattern and correct it before I want to shoot myself two weeks from now.

And now for the real big question......

How can a place full of DQNs know so much more and be more sensible than the enterprise eggheads populating places like java.net? It's mind boggling! Could /prog really be some soopa-secret hideout? Stay tuned, next week, for...uh...something!

Maybe because far, far, FAR too many people skip the whole learn step.

>>14
The real big question is how much bullshit have you taken from your boss, your faggy PC magazines featuring advanced tricks on how to install an extra DVD drive to watch legally purchased and regionalized movies, and your one week business computing course before coming here to write that?

The people posting here are programmers. Some novice, some intermediate, and some expert, as proven by different posts in different threads. They are the ones doing the real thing in their spare time, and they want to do it in the best and most comfortable way, giving spare time is unlimited, and they don't have to respond to a shithead manager who tells them what language to use, but wouldn't know how to write a heapsort function.

Haven't you wondered why is Java so popular among managers, consultants, and large corporations who are all about "business, business, business, lolz" and buy their fagged up magazines where Sun and M$ have paid to say "Java is serious business", ".NET rox", while it's tremendously unpopular in free software that's designed and written by real programmers? Java is the new Cobol. Nobody in his/her sane mind would do that. You code in Java at work because you're getting paid for it, some retarded manager is wasting money on it and you're making money for longer thanks to it. Then you come home with your money and do somehting you really like. Admittedly, I wouldn't use Java for absolutely anything I wanted to do, unless I'm getting paid.

If my boss were dumb enough to measure my productivity in lines of code, I would definitely want to use Java.

>>16
True.

>>14

How can a place full of DQNs know so much more and be more sensible than the enterprise eggheads populating places like java.net?

everyone in ADTRW (wait no 4chan) is a CS major

>>15
This person speaks the truth. Particularly the "java is the new cobol" bit.

>>15
Maybe I wasn't being clear enough:
DQNs = good
enterprise = poop

Or maybe I should have used poopheads instead of eggheads?
Let's be clear: I _HATE_ Java, the so-called 'enterprise' consultanc---sorry, community built up around it, the millions of useless certifications and courses built up around it (Have you ever seen the kind of shit Sun certified architects pull out of their asses?)

| Java is the new Cobol.
This is funny because this is exactly what I tell anyone who thinks that using java is a remotely good idea. Currently I'm waiting for the day my boss realizes that Java is the cause for all the project failures. But then there's these 'special' Sun people that keep appearing in the office. All our projects that went off completely without a hitch had absolutely no java in them, and absolutely no management input regarding technology.

This is our java project lifecycle:
1) Sun dangles carrot.
2) Management forgets everything that's happened before and decides everything MUST be in java.
3) Project fails horribly
4) Post mortem points at java making everything too convuluted and pro-java guys being completely clueless.
5) Goto 1.

>>18
And CS Masters in javalalaland are a dime a dozen. And yet they're mostly idiots. Then again, most CS courses nowadays are papermills full of java shit; you're lucky if you get one that isn't. I had the wonderful displeasure of interviewing some; many couldn't even figure out how to reverse a string.

most CS courses nowadays are papermills full of java shit; you're lucky if you get one that isn't.
When I was choosing CS courses, I divided all the potential choices into two categories: Java unis, and others. The Java unis were discarded, leaving me with a manageable set of choices. What happened? Somewhere in between my applying for a place and starting the course, the uni turned into a Java uni. I was displeased with the entire three years I spent there.

My uni was a Java uni, but it was OK as I had the option to take Prolog in the final two years instead, which was MUCH more interesting.

Nowadays, I program mainly in C# because it's what I use for work. And I can't be bothered to do any programming for fun any more either, work also took care of that urge :-|

Am I the only person lucky (or unlucky) enough to have used any number of languages in uni? Java, VB, C, C++, Prolog, Lisp, Tcl, asm?

This is overseas. Is the stuff in the US really going all Java?

>>23

Actually, the trend-setting uni's in the US are currently moving away from Java once again.  Java was a 4-6 year fad that's going out of style as uni's realize that undergrads who've never programmed have a ridiculously hard time grokking Java OO.

Well, to be honest, people who have never programmed before shouldn't be in a CS stream. That's like deciding you want to be a callgirl when you're still a virgin.

Not that I mind. Java syntax is simple enough, but the language is fugly. How it ever got mindshare is quite beyond me.

If I were the designer of a language like Java, I'd be embarrassed to put my name on it. I don't know what Gosling is thinking.

Am I the only person lucky (or unlucky) enough to have used any number of languages in uni? Java, VB, C, C++, Prolog, Lisp, Tcl, asm?
Well in addition to Java I used C, Scheme, Prolog, bash and asm, but only very basically. Like, one module was half C and half bash, another module was half Scheme and half Prolog, one module for asm and the rest of the 3 year course was taught in Java.

Oh there was this one lecturer who did everything in Maple, but that was just lawl.

>>25
To be honest, Java started out ok....then 1.2 come out and something went horribly wrong.

It's also unfortunate that a lot of people take up CS because it's 'in'.


| How it ever got mindshare is quite beyond me.
Bubble. BS Marketing. Market it to the managers (crossplatform, WORA, blah blah BS BS, etc), keep all the developers and people with technical know-how out of negotiations (don't forget to buy our super expensive servers!), then use the managers to force feed it down the chain. Result: Java adoption shoots though the roof because you need so many damn people just to do one damn simple little thing and doesn't bloody work properly in the end, hordes of disillusioned and pissed off developers.

>>25, >>27, et al

Why the fark does every thread in /prog/ turn into a damned Java thread?  Aren't the 8 that already exist in the top 10 enough?

a) It's a thread about OO, and
b) Java is one of the two biggies that claims OO, also
c) We really hate Java, and want to vent about it.

>>28
Seems we have a lot of disgruntled Java programmers in here.

Getting back to Factory Classes...

The biggest advantage is to insulate one layer of code from changes in another.  The user of the factory doesn't need to know anything except the virtual interface of the factory.  As new items are added to the factory,  clients of the class don't have to be re-compiled.  A major win if you are building a large system.

We could keep adding layers for everything. How about a dictionary layer in case we feel like changing the names for everything. How about a number abstraction layer in case we want to change Math axioms. How about a language parser in case we want to change Java.

You need to decide where to stop abstracting with common sense. Most of Java's abstractions waste in development and maintenance far more time than they save in the long term.

>>31
That's not what factory classes are for at all. That's what regular classes are for. Don't listen to him >>32!

>>27
Makes me kinda glad I work at a tiny company where all of the app development is done by two people (including me). Everything we do is in Visual C++, doesn't use Java or .NET except in vendor libraries (the less said about those the better), and there's no pressure from management (the owner, basically) to use Java or C# or whatever. Which is nice, because every time I've looked at Java, I've just sort of stared at it and moved on to something else because it looks *bad*.

WELCOME TO THE PAST BITCHES, FUCKING ENTERPRISE

WELCOME TO THE FUTURE BITCHES, FUCKING >>40

*sigh*

/prog/ used to be good

Wow yeah, /prog/ used to be really good.

what the hell happened?

>>39
Someone posted /prog/ to reddit.

>>35-37,40 is what happened.

>>42 is what happened.

>>42
The answer to everything?

have you read your gang of four today?

>>44
I only read it before going to sleep so that my dreams become pleasant, but my code doesn't become Enterprise.

Goddammit. I was reading this thinking "Holy shit, decent answers without MEME SPOUTING READ SICP all over the place?" Then I looked at the timestamps.

Gamma et al

>>46
Ah, how naive posters were back in the day -- even I was one of them.  Now I have learned.

Read SICP.

We didn't used to have to take no factory classes to run a sweatshop back when I was young, no sirree bob.

often What the fuck   this is at   an all time   Game Babes As   for the Anime   Babes I love   women but I   invented This may   surprise you but   I invented This   may surprise you   but I invented   This may surprise   you but I   would dare say   if you want   to take If   you wish to   program on a   journey of self.

WARNING: NECRO BUMP - DO NOT REPLY

>>52
Or you'll what?
Yeah that's right faggot, just walk away.

Don't change these.

Name:		Email:
Entire Thread Thread List