Unmaintainable Java Technique

In in doubt, mark methods 'private'. If you aren't *sure* that users of your API will need access to a method, then they don't need it, right?

Use post-compilation bytecode processing of your classes. With OOP (polymorphism etc.) you never know what code will be really executed, so why to give any hope to guess it?

Design in such a way that programmers need to write code in the form of object.getX().getX(). For bonus unmaintenance points, ensure that getX() and getX() return different types.
I find this one particularly funny because it's built into the Java API. In Java1.3 (which I'm still forced to use) there is a Calendar.getTimeInMillis() method but it is protected so I can't get at it unless I want to subclass it and wrap it. Thus I'm forced to use Calendar.getTime(), which returns a Date, and then Date.getTime() to return time in millis, thus producing calendar.getTime().getTime() where X and Y are two different return types :).
(This condition has apparently been fixed in Java1.4 by removing the protected restriction from Calendar.getTimeInMillis).

Alan, for a more comprehensive list of techniques, check out

http://mindprod.com/unmain.html

> if (number.isEven() == true) {
> return true;
> } else {
> return false;
> }

I find this so annoying that I wrote a PMD rule for it - see SimplifyBooleanReturnsRule here:

http://pmd.sourceforge.net/rules/design.html

Tom

... and those

1)Always create a java.lang.String as
String something = new String("something");

2)Do not bother creating object when you can pass just a list of parameters to a method:
void someMethod(int aParam1, String aParam2, byte[] aParam3, Object aParam4,String aParam5,String aParam6) {...}

3) Circular dependancies among packages will add more fun to your development.

4) Do not forget to add public abstract to all methods declared in an interface.

5) Test every parameter for null. Who knows what idiot will call your method ?

6) Make sure that at least several classes have public inner interfaces. See Netbeans code for references of how to do it.

7) If you make every method and variable public, you will not have any problem accessing what you want.

ResultSet res = prepStmt.executeQuery();
if (res != null && res.next()) {
...

In both "Practical Java" and "Effective Java" it's suggested to return zero-length arrays and collections instead of returning a null pointer. This avoids the "if (arr == null)" and makes code shorter and easier to read.

Use constructor as a function!

For instance, if you are required to:
1) build an object, initialise data,
2) invoke functions to log text files, calculate whatever…

Do not bother to do it all step by step! Simply declare functions as static(even if they are using non static data) and invoke them in the constructor body. Add them all, the more the merrier!

This is an ingenious way to relieve the burden from your code. Instead of creating an object and then invoking functions(what a tedious routine), simply instantiate an object and let it’s constructor do all the work in the background.

Sounds like fun, doesn’t it?

Language == C#
.ToString() pitfall

Use object .ToString() function or System.Convert.ToString()?
That is the question!

I recommend using .ToString() function as often as possible. This is an inherited function, defined in the object class, root class of all objects. That’s why all objects must implement it by overriding it, or simply inheriting it.

Sadly, if .ToString() of an uninitialised object(value == null) is invoked, the program crashes. That’s OK, the object does not exist, thus it’s ToString function does not exist – it’s not declared static. To compensate use:

if(obj1 != null){
str_target = obj1.ToString();
}
else{
str_target = “”;
}

It would be really stupid to use System.Convert.ToString() and avoid the problem. It would make ones life as a programmer quite dull.

Use less specific types for internal fields and for getter methods, even when there is no doubt about the specific type. If anyone complains about all the casts, argue that this is the price to pay for collecting common code in an abstract super class.

In the following example, Tiger extends Cat. Note how elegantly TigerCage exposes its contents as merely a cat. This will add fun, casts, and checks for future generations of developers.

---

public abstract class CatCage {
  private final Cat cat;
  public CatCage(Cat cat) {
    this.cat = cat;
  }
  public Cat getCat() {
    return cat;
  }
}

public class TigerCage extends CatCage {
  public TigerCage(Tiger tiger) {
    super(cat);
  }
  public void Foo() {
    if ((Tiger)getCat()).isBengal() { ..
    }
  }
}

---

Casting Cat to Tiger in the TigerCage class is a nuisance but at least it is done in some kind of context. The real impact lies in code like the following:

public class TigerHandler {
  public void handleCage(TigerCage tigerCage) {
    Cat cat = tigerCage.getCat();
    if (cat instanceof Tiger) {
      // this should always be the case
      Tiger tiger = (Tiger)cat;
    } else {
      // does this ever happen? Should ask the
      // previous developer but he was sacked for
      // some reason. Should I throw a
      // FelineException? Log an error? Quit?
    }
  }
}

---

PS. Bonus points awarded for initializing important stuff in the block where Cat is cast to Tiger. After all, we all know that the Cat in a TigerCage is always a Tiger so what could probably go wrong?