OOP fail
-
A guy on my team designed a message to transport a couple of Serializable (Java) strings from program A to program B via JMS. Ok, just set/get a bunch of strings in the (JMS) Message's map and you're done.
This guy decided that we should create a generic message payload wrapper for the single entity to be transported.
interface IPayload { Object getPayload(); }
class Payload implements IPayload {
private Object payload;
public Payload(Object o) { payload = o; }
public Object getPayload() { return payload; }
}What it could have been:
interface IPayload<t><T> { T getPayload(); }
class Payload<t><T> implements IPayload<t><T> {
private T payload;
public Payload(T t) { payload = t; }
public T getPayload() { return payload; }
}
</t></t></t>Of course, since it's only used in one place and will never be reused anywhere else because of the nature of what it is, they could have just put a private member in the class where it's needed:
private XXX xxx; // plus getter/setter
In so doing, he managed to defeat type safety at every turn.
-
Umm, what is the point of IPayload (the <T> version or the object version) to begin with? Wrapping a single object in a wrapper just for the sake of using a "standard interface" seems rather pointless... so instead of an Integer you have a Payload<Integer> (or a Payload where you have to cast the result of getPayload() to Integer) - unless the Payload object has some functionality of its own, why bother?!
-
Now you're seeing them doing this stuff, you can tell who's written the worst of the shit you've been mopping up after this last couple of months. The question is: do you educate or eradicate?
-
@Matt Westwood said:
Now you're seeing them doing this stuff, you can tell who's written the worst of the shit you've been mopping up after this last couple of months. The question is: do you educate or eradicate?
Eradication is preferred, but not viable. Education gets lots of head-nodding, but very little comprehension: But it's an Object!
-
@ekolis said:
Umm, what is the point of IPayload... why bother?!
Precisely! The whole thing should just go away in favor of a simple private member + get/set methods.
-
You kids with your generics and you IDE autocomplete features... In my day we would jot that stuff down on post-it notes and we'd be grateful. And every once in a while when we really felt on top of our game we'd even use reflection. We wouldn't be caught dead using this fancy-pants hand-holding trickery. Besides that stuff is just a fad.
-
OOP is The Real WTF (tm) here. It's OOP that even allows your colleague to write crap code like that. Don't tell me about "good OOP" versus "bad OOP", and how certain other people besides you are Just Doing It Wrong (tm). The ability to abuse Object in that way is a product of OOP. Sure, even C has (void*), the low-level equivalent of Object, but nobody is touting (void*) as anything other than a low-level hack (unlike OOP).
Most development paradigms give the developer enough rope to hang himself if he's so inclined. OOP goes several steps further. It cleans the contacts on the metaphorical electric chair, bribes the governor to prevent last-minute pardons, sets up an observation room for the victims, calls a priest, and cooks an elaborate last meal. It's that intent on screwing the developer over (and it succeeds mightily).
-
Too obvious 0/10.
-
@bridget99 said:
OOP is The Real WTF (tm) here. It's OOP that even allows your colleague to write crap code like that. Don't tell me about "good OOP" versus "bad OOP", and how certain other people besides you are Just Doing It Wrong (tm). The ability to abuse Object in that way is a product of OOP. Sure, even C has (void*), the low-level equivalent of Object, but nobody is touting (void*) as anything other than a low-level hack (unlike OOP).
No, the real WTF here is java. Wasn't it Alan Kay's quote that went something like "When I invented the term [i]Object-Oriented Programming[/i], it wasn't Java I had in mind." Or maybe that was about C++, but same problem. Strong Typing doesn't belong in OOP... it just muddies up the possible abstractions and re-use so that you get garbage like this.
-
It was C++ but whatever. A bit better attempt than the previous guy.
On topic. Always found great delight in seeing yet another object-wrapper type. You can never have enough wrappers.
-
I don't get it. You want to serialize an object to transport it via JMS - why another Interface/Object for that? If it's serializable, then serialize it! You just have to decide what output you want.. byte[], XML, JSON.. whatever..
