• Maarten (unregistered)

    Then I wonder what all these 151 Lines Of Code do.

    CAPTCHA: onomatopoeia

  • Dan (unregistered)

    Yes, but 151 lines of code can justify a week of pay. Trying to stretch a Boolean into 40 hours is probably going to be more difficult. There's not really much more debugging that needs to be done for it.

    CAPTCHA: wigwam

  • (cs)

    YesNoFileNotFoundFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase());

  • (cs)

    It looks like it does more than check a boolean value. It checks a string to see if it equals what the YesNoFactory says is "yes" or "no".

    Perhaps it has to parse documents in different languages, where it can expect "Yes", "Oui" or "Ja" as input.

  • (cs) in reply to spr
    spr:
    It looks like it does more than check a boolean value. It checks a string to see if it equals what the YesNoFactory says is "yes" or "no".

    Perhaps it has to parse documents in different languages, where it can expect "Yes", "Oui" or "Ja" as input.

    Nothing shows that getDescription() does more than returning a String.

  • Kluge Doctor (unregistered)

    I, for one, would like to see the code in its entirety. I will reserve judgment until then.

  • snoofle (unregistered) in reply to Kluge Doctor

    I've seen instances of stuff like this, but it was usually in the context of "there is this framework, and everything that needs to work with it is required to use the same sort of design patterns", so simple stuff winds up getting ridiculously overdesigned like this. I'm not agreeing with it; just saying that it happens.

  • Coffee Maker (unregistered)

    Except that until recently, Java didn't have ENUMs...

  • Richard (unregistered) in reply to Maarten
    Maarten:
    CAPTCHA: onomatopoeia

    Do I care?

  • sec (unregistered) in reply to XIU

    Yes, but perhaps it checks your language and returns a different string depending.

  • (cs)

    I saw this post title in the RSS feed and thought "please let it be another soul-crushing pattern abuse post." I wasn't disappointed.

  • Tom Woolf (unregistered)

    Some software developers deliver their source code and give the client the option of modifying it themselves. That is a very nice selling point. However, it can take away from later consulting/modification opportunities.

    By including stuff like this, they can make the code virtually unreadable to inexperienced folks, or just make it too time consuming. That leads to calls from the client stating they need the developer to modify their system.

    The company I work for does deliver source code (straight-forward code, not intentionally twisted beyond recognition). However, a company that did consulting modifying our code would install 2,000 lines of code with all sorts of crap to hide the 100 lines of actual useful code.

  • Deron Meranda (unregistered)

    And they make fun of C having an obfuscated code contest, why?

  • (cs)

    The real WTF is they haven't added another layer of abstraction using the Spring framework.

  • (cs)

    Dale's problem is that he just doesn't understand the intricate design patterns applied here. Just use a boolean? Bah. Anyone can do that. How does that demonstrate your grasp of the complex concepts involved?

  • jimjim (unregistered)

    But you dont get it!

    No matter what, this is what your final implementation...

    Your objects will be created by a factory, and you will have to use named function to do operations like comparing

    No, wait a minute...

  • ammit (unregistered)

    Gads! Is this seriously professional coders turning this out?

  • Eric (unregistered)

    This is a prototype for the Male/Female factory, and soon to be released On/Off factory. Copy and paste is a wonderful thing!

  • volpone (unregistered) in reply to lgrave
    lgrave:
    YesNoFileNotFoundFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase());
    Nice. You made me spit out my coffee, you jerk. :)
  • Holy Roller (unregistered) in reply to Richard
    Richard:
    Maarten:
    CAPTCHA: onomatopoeia

    Do I care?

    You're asking the wrong person.

    CAPTCHA: paint (bad timing on this, it should have been "burned", dang)!

  • Anon (unregistered) in reply to Coffee Maker
    Coffee Maker:
    Except that until recently, Java didn't have ENUMs...
    Still doesn't. If you were to try and create a Boolean as a Java enum, you'd wind up with three values.

    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.

  • (cs) in reply to Deron Meranda
    Deron Meranda:
    And they make fun of C having an obfuscated code contest, why?
    Because this isn't obfuscation but needless complication.
  • NeoMojo (unregistered) in reply to Richard
    Richard:
    Maarten:
    CAPTCHA: onomatopoeia

    Do I care?

    Wow, I didn't even notice. I've gone captch blind! yay!

  • CM (unregistered) in reply to Anon

    You mean "..If you were to try and create a boolean as a Java enum.." As far as I know, Boolean can still be null :)

  • Geekwad (unregistered)

    "I can't imagine a single scenario ..."

    What if you don't want data, you want a model? What if the model needs to support subscribers who might be in another process written in another language running on a different server? What if you are talking to your subscribers with a lossy channel (for instance, the ultimate consumer might even be a human, who are inherently lossy) and need to keep track of your client's states as well as your own?

    It would be awful to have a carefully documented and modular implementation that spans gosh, how many lines did you say, again?

  • (cs) in reply to Anon
    Anon:
    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.
    Non sequitur. Just because something is similar to but doesn't work exactly like the corresponding construct in your favorite language does not make it worthless. Snytactic sugar most certainly isn't, or would you prefer your C without the [] operator (syntactic sugar for pointer arithmetics), without structs (syntactic sugar for multiple variables) and without methods (syntactic sugar for goto)?
  • Anon (unregistered)

    Atleast he didn't do that with Integer. Consider the interface com.enterprise.factory.provider.manager.paula.web.business.1234567890.java or maybe it would have been Integer1234567890.java since who wants those classes where the classnames make no sense.

    Integer1 implements Integer1234567890... jeesh how can any object implement IYesNo interface? Yes implements IYesNo (except not No). Well I guess its optional.. here is the abstract class in supercool pseudo:

    Maybe implements IYesNo{ IYesNo isYes(){ throw new UnsupportedOperationException(); } IYesNo isNo(){ throw new UnsupportedOperationException(); } }

  • (cs) in reply to Eric
    Eric:
    This is a prototype for the Male/Female factory, and soon to be released On/Off factory. Copy and paste is a wonderful thing!
    No no no: bools are supposed to be like this:

    On-Off-Left; Male-Female-Turquoise; (and as posted above: True-False-FileNotFound)

  • Kuli (unregistered)

    I'd like if no if only a single line of these is hand-written. I suggest that s.o. created an YesNo-Entity in the (UML?) model (and we don't know if there might be some sense in it), and the code generator generated all these wonderfull classes.

    I wouldn't care about such thing. They get generated, and then? Who cares? They don't eat bread.

  • Paul (unregistered)

    This looks like something used in a Java course to demonstrate the use of interfaces and the factory pattern. If this got into production, it's likely from an inexperienced programmer who missed the prof telling him it's just an example and you'd use such a pattern only sparingly.

    I honestly haven't seen such egregiously overengineered code myself, but here at work, most Java programmers still overuse interfaces. Just about every "business"-logic class is the single implementation of an Interface, with no way (not even a factory) to get an instance of another implementation without wholesale refactoring.

    I'm one of those mavericks who insists on using interfaces only where they come in useful, with the idea that it's easier to promote a class to an interface in the future if it's needed, than it is to reduce the complexity of such code.

  • (cs) in reply to Geekwad
    Geekwad:
    "I can't imagine a single scenario ..."

    What if you don't want data, you want a model? What if the model needs to support subscribers who might be in another process written in another language running on a different server? What if you are talking to your subscribers with a lossy channel (for instance, the ultimate consumer might even be a human, who are inherently lossy) and need to keep track of your client's states as well as your own?

    It would be awful to have a carefully documented and modular implementation that spans gosh, how many lines did you say, again?

    How about that? I think we found the guy who wrote today's wtf.

  • (cs) in reply to Richard
    Richard:
    Maarten:
    CAPTCHA: onomatopoeia

    Do I care?

    Sounds like you do. :)

  • Patrick (unregistered)

    Perhaps it's a useful set of code that's just awkwardly named. It's not necessarily the fault of the guy who wrote it that it was so.

  • Anony-Mouse (unregistered)

    Two words:

    Job Security.

  • charon (unregistered)
    For a class that has a value of either yes or no.

    Classes don't store values, their instances do (in properties).

  • Not Dorothy (unregistered)

    Slacker!

    What's with the array[0]? Take it back and don't come back until it is completely enterprisy?

  • (cs) in reply to Maarten

    Someone should be shot. Repeatedly. With a large caliber weapon. Starting with the extremities and working inward.

  • AnnC (unregistered) in reply to Tom Woolf
    Tom Woolf:
    Some software developers deliver their source code and give the client the option of modifying it themselves. That is a very nice selling point. However, it can take away from later consulting/modification opportunities.

    By including stuff like this, they can make the code virtually unreadable to inexperienced folks, or just make it too time consuming. That leads to calls from the client stating they need the developer to modify their system.

    The company I work for does deliver source code (straight-forward code, not intentionally twisted beyond recognition). However, a company that did consulting modifying our code would install 2,000 lines of code with all sorts of crap to hide the 100 lines of actual useful code.

    What's the saying? Never attribute to malice that which is adequately explained by stupidity.

  • Matt (unregistered) in reply to Geekwad
    Geekwad:
    What if you don't want data, you want a model?

    And I do. I'm just not sure that Java is the best way of getting one...

  • awfawefwfw (unregistered)

    Yeah, but it's a fluent interface. Therefore, it's good because it's the flavour of the moment.

  • (cs) in reply to Matt
    Matt:
    Geekwad:
    What if you don't want data, you want a model?

    And I do. I'm just not sure that Java is the best way of getting one...

    If you want a model, anything to do with computer programming is a rather bad way; try doing rock music or acting instead.

  • Lateef (unregistered) in reply to CodeRage

    +1

  • JB (unregistered)

    Job security FTW.

  • (cs)

    You guys have it all wrong. I would assume that this factory loads the definitions from a database table. What happens in 100 years when the boolean type supports -Maybe -Somewhat -I don't know

    • Not Sure -File not found

    All you people with your legacy code will be screwed, where as this application is set since they just need a minute to add the new definitions to the database.

  • jewnumeration (unregistered) in reply to Anon
    Anon:
    Coffee Maker:
    Except that until recently, Java didn't have ENUMs...
    Still doesn't. If you were to try and create a Boolean as a Java enum, you'd wind up with three values.

    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.

    Dude -- null means false.

  • Geekwad (unregistered) in reply to gabba
    gabba:
    Geekwad:
    "I can't imagine a single scenario ..."

    What if ...

    How about that? I think we found the guy who wrote today's wtf.

    Look, my point is, the WTF being presented is that someone applied a bunch of design patterns to something trivial. But, the "something trivial" is never described. We are encouraged to infer it is trivial because it probably involves a boolean value, but there's no real information. We are given evidence that several well-known patterns are being used, but we are given no evidence that they are being mis-used. We're holding some developer up for ridicule based on nothing more than some path names. That sounds pretty WTF to me.

  • Anon (unregistered) in reply to jewnumeration
    jewnumeration:
    Anon:
    Coffee Maker:
    Except that until recently, Java didn't have ENUMs...
    Still doesn't. If you were to try and create a Boolean as a Java enum, you'd wind up with three values.

    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.

    Dude -- null means false.

    I was wondering if any idiot was going to say that.

    Since Java enums are objects (another WTF for another time), you're allowed to invoke methods on them. You can't invoke methods on a null object. A simple example would be the name() method which returns the name of the constant.

    By allowing null to be a legal value, you break the entire concept of a Java enum. Which, since Java allows null enums, is already broken.

  • (cs) in reply to Geekwad
    Geekwad:
    gabba:
    Geekwad:
    "I can't imagine a single scenario ..."

    What if ...

    How about that? I think we found the guy who wrote today's wtf.

    Look, my point is, the WTF being presented is that someone applied a bunch of design patterns to something trivial. But, the "something trivial" is never described. We are encouraged to infer it is trivial because it probably involves a boolean value, but there's no real information. We are given evidence that several well-known patterns are being used, but we are given no evidence that they are being mis-used. We're holding some developer up for ridicule based on nothing more than some path names. That sounds pretty WTF to me.

    True. An interface named IYesNo might model, say, a ham sandwich rather than a boolean. He's right -- there's no wtf here.

  • (cs) in reply to Anon
    Anon:
    jewnumeration:
    Anon:
    Coffee Maker:
    Except that until recently, Java didn't have ENUMs...
    Still doesn't. If you were to try and create a Boolean as a Java enum, you'd wind up with three values.

    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.

    Dude -- null means false.

    I was wondering if any idiot was going to say that.

    Since Java enums are objects (another WTF for another time), you're allowed to invoke methods on them. You can't invoke methods on a null object. A simple example would be the name() method which returns the name of the constant.

    By allowing null to be a legal value, you break the entire concept of a Java enum. Which, since Java allows null enums, is already broken.

    Actually you are partly wrong. Enums are fine having null values and remaining as such and this makes them NOT a boolean.

    Booleans (in most languages) are two valued variables that can have a third state of uninitialized. This state effectively means null. Now if you can not safely assume a null value is actually one of two predefined values you do not have a boolean.

    For example, you can have a boolean for a finished state, true means finished, false mean unfinished. If the value is uninitialized you can assume false because if the item was finished the boolean would have been specifically set to true.

    Alternatively, the safe value could be True for booleans that mean something else such as an incomplete flag. In this case null = true because of the usage and name of the boolean variable.

    So yes internally there are three theoretical states for a boolean variable but the null state should be safely assumed to be one of the other two states and when encountered the boolean can be safely initialized to that state effectively getting rid of all null issues.

    So while the null = false statement isn't really correct, the idea behind the state is spot on. And even though java makes all enums an object and null objects don't allow the methods to be called, one used as a boolean can be safely initialized to it's safe state and then used.

  • (cs)
    Interface: 10 lines (4 Lines Of Code w/o comments) core/src/com/.../enterprise/util/codetable/IYesNo.java

    ...The Real WTF(tm) is obviously the use of C#-istic "I" prefix on a Java interface...

Leave a comment on “Taking a Good Thing Too Far”

Log In or post as a guest

Replying to comment #160830:

« Return to Article