Comment On These Go To Fourteen

Company policy:

- never use collections
- never use generics

This one's hard to call - with annonymization, "one"..."fourteen" might have been meaningful variable names, in which case a lot of it would make more sense. Of course, brute-forcing it in the middle of a loop is a WTF in and of itself...

Note from Alex: Only changes to the originally submitted code was the "snipping" and some formatting.

Now that's a WTF! I love that there's an explanation about how this is "elegant"... I'd say it's more like elephant s***.

I do not understand the solution. I do not understand the problem they're trying to solve. I do not understand what's "elegant". I think I have reached Nirvana...

Shenanigans. There is no way this code is real.

"//ED: By the setter of the ninth attribute, the argument name was
// understandably changed to entry. All those numbers are tiring
// to write!
public void setFourteen( String entry)
{
this.fourteen=entry;
}
"

That's understandably ;-(

Regards
Friedrich

when i see people like this getting hired.. i get assurance of a bright career...

Is it very hard to declare a dynamically sized array of strings in java? I realize doing so would break the beautiful encapsulation present in this classy design, but that would only really be a problem if you ever wanted to use a different type of string. Somehow I think the benefits of that approach would outweigh the inherent risk.

Or if you really, really want a class and be enterprisey about it, just do

class ListBean {
public:
enum numbers { one, two, three, ..., fourteen };

void set (numbers Number, string Value);
string get (numbers Number) const;

private:
vector<string> Values;
}

(yes, this is C++ - I don't know java well enough). Far less code, and an API that is bad enough that it should make all those enterprise-clowns cry with happiness.

But sir! We have to have 15 items or all our online transactions will grind to a halt!

15 ITEMS?!?! OH GOD! WHEN WILL PEOPLE LEARN?! IF ONLY THEY'D HAVE MADE IT WITH 15 ITEMS!

Right... but this one goes to eleven.

</spinal tap>

package com.initrodeglobal.util.presentation;



public class FourteenEnterPriseListBean extends ThirteenEnterPriseListBean

{

   private string fourteen;



   public FourteenEnterPriseListBean (String one, String two, String three, 

                                      String four, String five, String six, 

                                      String seven, String eight, String nine,

                                      String ten,String eleven, String twelve,

                                      String thirteen , String fourteen)

   {

      super (one, two, three, four, five, six, seven,

             eight, nine, ten, eleven, twelve, thirteen);

      this.fourteen = fourteen;

   }



   public void setFourteen (String entry)

   {

      this.fourteen = entry;

   }



   public String getFourteen ()

   {

      return this.fourteen;

   }

}

The next-worst part is that they actually typed in all those getters and setters... any half decent editor can do it for you.

Wru!

Euh,
public ListBean(ArrayList params)
{
for (int a=1;a<=params.size();a++) switch (a)
{
case 1 : if (params.get(0) != null)
this.one=params.get(0).toString();
break;
case 2 : if (params.get(1) != null)
this.two=params.get(1).toString();
break;

... snip ...

case 14 : if (params.get(13) != null)
this.fourteen=params.get(13).toString();
break;
}
}
WTF, this just feels so wrong!

Nope. Won't work, constructors aren't inherited.

Hans:

Is it very hard to declare a dynamically sized array of strings in java?

Collection<String> variablySizedStringArrayForHans = new ArrayList<String>();

and then just .add() any string to it that you want. This provides a nice amount of polymorphism, since the collection interface allows enough functions to do anything, and you can choose you implementation (lists, sets etc..)

or for kicks, if you want your values accesable by a lable, use a map instead of a collection

Tassos:

Nope. Won't work, constructors aren't inherited.

if you are referring to cheatah, yes it will, he is calling super(13 args), not this(13 args), which wouldnt work. He is just calling the 13 arg constructor of the superclass, which does have that ctr

Tassos:

Nope. Won't work, constructors aren't inherited.

if you are referring to cheatah, yes it will, he is calling super(13 args), not this(13 args), which wouldnt work. He is just calling the 13 arg constructor of the superclass, which does have that ctr

And THIS is exactly why programmers should be hired/promoted based on merit, not seniority. I've seen more than my share of companies where the lead/senior developer only had that position because he was with the company for years (or was its first programmer, or whatever), so had seniority but didn't know his ass from a hole in the ground or how to properly write software. Yet bozos like these constantly are in charge of better developers, and make asinine decisions like we see here.

Tassos:

Nope. Won't work, constructors aren't inherited.

I'm guessing you're referring to the fact that FourteenEnterPriseListBean won't have constructors for one through thirteen list items. That's okay - you'd just instantiate a ThirteenEnterPriseListBean (or other appropriate class) instead!

Does this make anyone else's stomach hurt? They import ArrayList and are too thick to use it? If that doesn't scream WTF than I don't know what does :-D

Err, its the new generation of programmers that come up with this crap.

"This way, we don't have to use the real object and can save memory."

Holy crud! That leading comment is by far the scariest bit of the whole WTF, especially with those constructors...

Well, obviously this class should implement Iterable<String>. How silly of them, now their memory efficient list can't be iterated!

It is clear that they intend to upgrade to HEX in the near future.

Csaboka:

Hooray!

Finally, we see someone who has mastered the FOR-CASE paradigm. Actually, he managed to mix it with the OO paradigm, making a new paradigm altogether. All we have to do is name the new paradigm and teach them to the new generations of programmers!

FOR CASE OO List. You could even make a cool anagram out of it: Socrates Folio.

Perhaps they just wanted a holder for a fixed number of related strings (like a Python tuple), without having to write

ArrayList<String> a = new ArrayList<String>();

a.add(one);

a.add(two);

a.add(three);

...

which is, after all, rather verbose. Of course, in that case they could have just used

a = new String[] { one, two, three, ... };

  public void setTwo( String two)

  {

    this.two=two;

  }

I expected to see

  public void setEight( String nine)

  {

    this.seven=eight;

  }

Happily there is no possibility of the compiler detecting this error since the "this" is implied everywhere that the compiler could have used its absence to be helpful.

Wow, that's a painful aggregation of pronouns for this early on a Monday morning. :-P

Cheatah:

package com.initrodeglobal.util.presentation;



public class FourteenEnterPriseListBean extends ThirteenEnterPriseListBean

{

   private string fourteen;



   public FourteenEnterPriseListBean (String one, String two, String three, 

                                      String four, String five, String six, 

                                      String seven, String eight, String nine,

                                      String ten,String eleven, String twelve,

                                      String thirteen , String fourteen)

   {

      super (one, two, three, four, five, six, seven,

             eight, nine, ten, eleven, twelve, thirteen);

      this.fourteen = fourteen;

   }



   public void setFourteen (String entry)

   {

      this.fourteen = entry;

   }



   public String getFourteen ()

   {

      return this.fourteen;

   }

}

That is just sheer elegance!

Csaboka:

Hooray!

Finally, we see someone who has mastered the FOR-CASE paradigm. Actually, he managed to mix it with the OO paradigm, making a new paradigm altogether. All we have to do is name the new paradigm and teach them to the new generations of programmers!

I name it the For Object Orientated Case ExtenDed Paradigm

Shortened to The FOOC paradigm, and rather aptly phonetically pronounced “Fooc-ed Paradigm”

Erik:

Right... but this one goes to eleven.

</spinal tap>

Made me cringe just reading this comment. I had a spinal tap when I was 3 due to meningitis. Guess thats why I have a phobia against needles.

Or

Arrays.asList(one, two, three)

Csaboka:

Hooray!

Finally, we see someone who has mastered the FOR-CASE paradigm. Actually, he managed to mix it with the OO paradigm, making a new paradigm altogether. All we have to do is name the new paradigm and teach them to the new generations of programmers!

I nominate FOOR-CASE.

I always wondered how to store multiple values in a class. Thanks for this tip !



:D

This code reminds me of a classmate of mine back in 8th grade. In English class, he rose his hand to ask the teacher, "What eloquent mean?" It took everything in me not to serve detention for laughing at the sweet sweet irony that had just unfolded before my eyes.

Csaboka:

Hooray!

Finally, we see someone who has mastered the FOR-CASE paradigm. Actually, he managed to mix it with the OO paradigm, making a new paradigm altogether. All we have to do is name the new paradigm and teach them to the new generations of programmers!

Maybe FOR-CASE-OOooohh...

Bosshog:

This code is so elegant, it makes me want to poke out my own eyes with a fourteen pronged fork.

Wouldn't it be safer to use a fifteen pronged fork?

Pay special attention to the constructor that takes ArrayList. If you squint a bit, it looks like a Duff's device. Or in this case, Dufus' device.

bd:

Pay special attention to the constructor that takes ArrayList. If you squint a bit, it looks like a Duff's device. Or in this case, Dufus' device.

Heh! I like that name.

I wouldn't touch this with a fourteen foot pole...

I'd need the fifteen foot pole to touch this.

I just died a little inside...

A dynamically-sized array is a Vector.

pitchingchris:

Erik:

Right... but this one goes to eleven.

</spinal tap>

Made me cringe just reading this comment. I had a spinal tap when I was 3 due to meningitis. Guess thats why I have a phobia against needles.

I do hope you realize he was referring to the movie, not the procedure.

I'm having a hard time believing this one. I could understand a junior programmer writing, say, the first 20 lines of code. Once they hit the constructor that takes the ArrayList, though, I'm pretty sure everyone would have realized that "hey, the ArrayList is the exact data structure I'm trying to represent!" and stopped immediately.

My only guess is that this constructor was actually written later by a more experienced developer that was too lazy to actually refactor the code properly. Maybe, for some reason, they were forced to keep this object around and got sick of calling a 14 argument constructor. Still doesn't make fetching the values any easier though...

On second thought, no, there's no way that this code is real. Must be some kind of bad dream that I'm having...

The real WTF is that they didn't use the automated Getters and Setters generation

I find this class very useful, but it has too many functions, which makes it slow. My improved version (in C++, also for speed):

#include <string>



template <int i>

class EnterpriseListBean : public EnterpriseListBean<i-1> {

private:

	std::string value;

public:

	virtual std::string get(int x) {

		return x == i ? value : EnterpriseListBean<i-1>::get(x);

	}

	virtual void set(int x, std::string value) {

		if(x == i)

			this->value = value;

		else

			EnterpriseListBean<i-1>::set(x, value);

	}

};



template<>

class EnterpriseListBean<0> {

private:

	std::string value;

public:

	struct NinjaStar {

		const char *what() {

			return "YOUR HEAD ASSPLODE";

		}

	};

	virtual std::string get(int i) {

		throw NinjaStar();

	}

	virtual void set(int i, std::string value) {

		throw NinjaStar();

	}

};



typedef EnterpriseListBean<0> GenericEnterpriseListBean;

This is the FOURTEEN-CASE paradigm, not the FOR-CASE one.
You should know that.

It's the FOURTEEN-CASE paradigm!

OperatorBastardusInfernalis:

I'd need the fifteen foot pole to touch this.

HAMMER TIME!