Found in our enterprisey business object factory
-
Need a business object.
BusinessObjectSuper x = BusinessObjectSuper.makeBusinessObject(SpecificBusinessObject.class);
Okaaayyy...
class BusinessObjectFactory { public BusinessObjectSuper makeBusinessObject(Class tomake) { /* some initialization and random stuff */ BusinessObjectSuper newobj = Class.forName(tomake); /* initialization of newobj by reflection */ return newobj; } }
Of course, the real question is, if you know what class you want, and have the class name, why not just make one?
-
This should be classified in the "I have no idea what I am building" moments.
-
Is there like... logging or something in the code you omitted?
-
Is there like... logging or something in the code you omitted?
No logging that I recall. Part of the problem is that Java is not usually my domain, and I only saw this over a desktop presentation from a coworker's desktop.
I don't recollect what the code before the instantiation was; I was mostly focused on the idiocy of it. The code following was reflection initialization...using methods defined by the superclass. That is, there was no need for the reflection since the initialization methods being used were all defined on BusinessObjectSuper.
It was pure reflection for the joy of reflection.
And the instantiation is idiotic. You have to specify the class? And do a .class() to get the Class object and then toString() it and build an instance by name? is that?
-
You probably know this masterpiece: Execution in the Kingdom of Nouns
-
Kind of sort of looks like what I saw today.
-
The thing I find particularly ironic, with respect to that article, about java's implementation of lambdas is that they are just a very small bit of syntactic sugar over something that it was always possible to do in java — in fact, I believe they went with the implementation they did specifically because it commonly was done. Logically, if you are passing something around, that means you are treating it as a noun. If the complaint is that java is very verbose, well I'm sorry, but sometimes its hard to cone up with succinct names for things. But the whole parts-of-speech business has always seemed pretty silly to me.
-
This could have made some sense if
BusinessObjectFactory
implemented an interface likeFactory
, and then you'd see references toFactory
throughout your code. That way, a different implementation that does more or less could be dependency injected.But instead, they didn't do that and you have totally pointless boilerplate.
Cargo-cult OOP.
-
Of course, the real question is, if you know what class you want, and have the class name, why not just make one?
Because factory pattern. That's why!
Filed under: Better Livin' Through Design Patterns?
-
@SomeDroneWorker "Ooooh, I just read this Design Pattern book, so I'm going to put it to good use. And that Factory Pattern? My Favorite! I'll use it everywhere."
Seen it, experienced it, nothing you can do but say "Oh $#!%"
-
Of course, the real question is, if you know what class you want, and have the class name, why not just make one?
I ask that every time I need to look at something in a web application I maintain. My predecessor did this for some reason, and it drives me insane every time I need to figure out where the eventual data is being fetched from.
Literally gets about ten layers down in some places, just to call a stored procedure that returns two fields...Because factory pattern. That's why!
Except this factory is designed to produce only one thing. And there are literally factories that build interfaces to create factories that make the object to call the function.
-
Well ... that is because this industry is littered with cargo cult "programmers" who know just enough to be dangerous, but not enough to know when to use which tool for which job as they busily copy and paste away from stackoverlfow and pray to the dead gods of the reel-to-reel era that they don't get caught not knowing something.
I am butchering this quote, and I don't remember where I got it from, but it applies here:
"We used to have goto statements in our code, and it was a mess, and we called it spaghetti code. Now we used object oriented techniques in our code, and in order to do anything we have to drill a dozen layers deep on everything before we hit any code that actually does something. We've traded spaghetti code for spaghetti architecture." :sigh:
-
cargo cult "programmers" who know just enough to be dangerous, but not enough to know when to use which tool for which job as they busily copy and paste away from stackoverlfow and pray to the dead gods of the reel-to-reel era that they don't get caught not knowing something.
Yeah. This site literally looks like someone who was taking web design classes, and ended up taking four different classes. Here's the progression (of the "front end" portion of the site, there's a "back-end" portion, but that basically starts at Area 3's state):
- Area 1: Simple MVC layout, lots of stuff copy-pasted, inline-css and javascript. Bah, whatever.
- Area 2: Templated MVC layout, with decorated properties on the model for enhanced functionality.
- Area 3: Abstracted MVC layout with factories to generate interfaces to the templates (I think this explanation is slightly wrong, there's a "repository" folder of classes there too)
- Area 4: Fsck it, we're going Angular, baby!
Not to mention the myriad of spelling errors for things like "account" (not how it appeared in the site, apparently nobody noticed or complained before I fixed it).
-
I hate the "front-end" movement and everything it stands for with the heat of a white-hot sun.
Angular, Backbone, Ember, Knockout, React, and all of their mutant offspring, can all die in a fire.
-
@Vaire Of those, I've only tried using Knockout, and it seemed simple at least. All the rest sound really complicated, but as someone who can understand WPF fairly well, that one seemed fine.
...though I haven't ever done much with it, and by now it's probably a 10-layer enterprise monstrosity.
-
@Vaire said in Found in our enterprisey business object factory:
"front-end" movement
-
The "factory pattern" implements a functor over its argument.
Functors are good. You can use them to encapsulate effects all the business objects need, without forcing them into a class hierarchy.
Inheritance is bad. Don't do inheritance. Do functors.
-
@Captain said in Found in our enterprisey business object factory:
functors
I don't think this word means what I think it means...
-
@Captain said in Found in our enterprisey business object factory:
Inheritance is bad. Don't do inheritance. Do functors.
... because...?
-
@Captain said in Found in our enterprisey business object factory:
Inheritance is bad. Don't do inheritance. Do functors.
That sounds like the sort of thinking that led to JavaScript's confusing prototypal model
-
Because inheritance causes a lot of unnecessary coupling, or requires multiple inheritance to get an object to inherit all of the behaviors it needs. Instead, you can tack behaviors on by sticking the behavior in a functor and decorating.
-
@Captain said in Found in our enterprisey business object factory:
The "factory pattern" implements a functor over its argument.
Functors are good. You can use them to encapsulate effects all the business objects need, without forcing them into a class hierarchy.
Inheritance is bad. Don't do inheritance. Do functors.
7/10, would recommend to others.
-
@Captain But how do functors help with my love life?
-
They don't, unless you're dating much geekier girls than I have found.
-
@Captain said in Found in our enterprisey business object factory:
Because inheritance causes a lot of unnecessary coupling, or requires multiple inheritance to get an object to inherit all of the behaviors it needs.
Or you could do what any sensible person would do and use interfaces to define behaviours
-
Yes, because interfaces always existed and you never have to understand legacy code. You also never want to add behaviors at run-time.
-
@Captain said in Found in our enterprisey business object factory:
You also never want to add behaviors at run-time.
The system I work on has pipelines where the behaviours are loaded at runtime. And what do they use?
Interfaces.
-
Superb! It's great that you don't understand what a functor is, or why you're using them.
-
@Captain It seems 'functor' is just a fancy word for 'function', and only used by people who pretend they're superior:
-
I'd be more likely to load exported interface implementations with MEF so I can compose my object graph when needed, honestly. I mostly use inheritance for things like property change notification.
The best part is, all that uses a bunch of jargon and buzzwords, but is simpler than most people's IoC frameworks, and accomplishes the same goal, with plugin support.
-
Yes, I feel so superior. Talking with somebody as uninformed and opinionated as you makes my bones ache.
It's good that you spent the 4 seconds to Google the definition, but it's sad that you lack critical thinking skills. THERE IS A TAXONOMY OF FUNCTIONS. A functor is a homomorphism on the canonical algebra for a type. "Functor" is a lot more informative than "function."
-
@Captain Personally, I couldn't care less what a 'functor' is; I work with languages that let me get stuff done
-
I get more done and earn more too.
-
@Captain Maybe, but people talk to me in the pub
-
@RaceProUK
You go to the pub? What a pleb.
-
Do you wear Burberry too?
-
@RaceProUK said in Found in our enterprisey business object factory:
Personally, I couldn't care less what a 'functor' is;
You get to learn. It's bloody simple: a functor is a function that takes another function as an argument (or more than one). You probably do that quite a bit; it's dead useful for getting stuff done with less code and less fucking up.
The only downside of functors is that they're a lot harder to analyse than simple functions.
-
@Captain said in Found in our enterprisey business object factory:
You go to the pub?
I'm British; British people go to the pub
-
@dkf said in Found in our enterprisey business object factory:
You probably do that quite a bit
Given how much I use LINQ, I use them loads :)
-
I think a point or two was missed.
- This use wasn't about inheritance: the factory requires every class passed in to to be a subclass of a particular superclass.
- It wasn't about lazy loading because the caller of the factory has to pass the .class() for the intended class, which of course meant it had to be imported.
- It didn't seem to be about initialization, since that was done through hardcoded method names accessed by reflection. I admit I don't know if those methods were abstract in the superclass, but...why not?
Mostly it seemed to be about, "Ain't reflection cool?"
Maybe there was something deeper I overlooked because this was a quick skim, but I doubt it.
-
@CoyneTheDup said in Found in our enterprisey business object factory:
Mostly it seemed to be about, "Ain't reflection cool?"
It is.
Right up until you realise it's just slowed your program down by 200%.
-
@RaceProUK said in Found in our enterprisey business object factory:
Right up until you realise it's just slowed your program down by 200%.
And that's not the biggest problem with it, either. Reflection is doing an end-run around the type system, except you can't really do that. You're trading compile-time safety for unpredictable run-time exceptions. Yay!
-
@another_sam said in Found in our enterprisey business object factory:
And that's not the biggest problem with it, either. Reflection is doing an end-run around the type system, except you can't really do that. You're trading compile-time safety for unpredictable run-time exceptions. Yay!
So let me make sure I get this: they turned Java into Javascript. Right?
-
@Magus Out of curiosity, have you ever used Prism which can use MEF as one of its IoC containers?
-
@Captain said in Found in our enterprisey business object factory:
Yes, I feel so superior. Talking with somebody as uninformed and opinionated as you makes my bones ache.
It's good that you spent the 4 seconds to Google the definition, but it's sad that you lack critical thinking skills. THERE IS A TAXONOMY OF FUNCTIONS. A functor is a homomorphism on the canonical algebra for a type. "Functor" is a lot more informative than "function."
You said homo...
-
@CoyneTheDup said in Found in our enterprisey business object factory:
the caller of the factory has to pass the .class() for the intended class
This is the bit that just makes me boggle over and over. There are reasons for sometimes using a factory to do what appears to be a simple construction, but not one of those reasons ever involves passing the class object in, taking its name, and then doing
Class.forName()
on that.Unless they're doing hairy stuff with
ClassLoader
s. But then I would want to run away and hide. That's where Java's really deep voodoo lies…
-
@powerlord Yes. Basically, I don't see the point. PRISM is crazily enterprisey, and while it can do a lot of things, 90% of that is available with almost no effort with just MEF, and MEF is part of the framework (Okay, it's a nuget package in Universal, but still). If you know you need PRISM, use it. Otherwise, use the thing I made in my thread about MEF here somewhere. That's a sufficient base to build upon and figure out what else you need.
-
@Magus I think the biggest problem in enterprisey teams is actually actually figuring out what shit is needed for the project.