AntiPattern

AntiPattern Nedir
Antipattern bir probleme bulunan faydasız hatta zararlı çözümdür.

God Object
God Object yazısına taşıdım

Magic String
Koddaki string sabitler. Şöyledir.

func(string foo) {
    if (foo == "bar") {
        // do something
    }
}

Exception'a Göre If
Metod çağrısının exception dönmesi bir antipattern. Şu kod kötü

public void proceedWhenError() {
   Throwable exception = serviceUp();

   if (exception == null) {
      // do stuff
   } else {
      logger.debug("Exception happened, but it's alright.", exception)
      // do stuff
   }
}

Bir çağrı durumu nesnesi dönerken exception'ı saklamak  daha iyi olabilir.

public class CallStatus {
    private final Exception serviceException;
    private final boolean isSuccess;
    public static final CallStatus SUCCESS = new CallStatus(null, true);
    private CallStatus(Exception e, boolean s) {
        serviceException = e;
        isSuccess = s;
    }
    public boolean isSuccess() { return isSuccess; }
    public Exception getServiceException() { return serviceException; }
    public static CallStatus error(Exception e) {
        return new CallStatus(e, false);
    }
}

Kullanmak için şöyle yaparız.

CallStatus status = serviceUp();
if (status.isSuccess()) {
    ... // Do something
} else {
    ... // Do something else
    Exception ex = status.getException();
}

ServiceLocator
ServiceLocator kullanımında, global nesneler kodun her tarafına bulaştıkları için test etmesi ve değiştirmesi zor bir yapı ortaya çıkıyor. Dependency Injection kullanarak ServiceLocator örüntüsünden kurtulmak mümkün.

Tramp Data
Tramp Data global nesne kullanmaktan biraz daha iyi ancak bence yine de Antipattern. Global nesne kullanan bir kodu kurtarmak için yapılır. Bu kullanımda bir nesne en alt seviyede kullanıldığı halde en üst seviyedeki çağrıya geçiliyor. Şöyle yaparız

higherlevel(newParam)->level1(newParam)->level2(newParam)->level3(newParam)

Yo Yo Problem
Karmaşık kod hiyerarşilerini anlamak için sürekli kodun içinde bir aşağı bir yukarı dolaşmaktır. Kodda daha anlaşılır isimler kullanılması durumu düzeltebilir. Açıklaması şöyle.

The assumption is that you don't need to yo-yo to the ZipCode class to understand the Address class. If ZipCode is well-designed it should be obvious what it does just by reading the Address class.

Programs are not read end-to-end - typically programs are far too complex to make this possible. You cannot keep all the code in a program in your mind at the same time. So we use abstractions and encapsulations to "chunk" the program into meaningful units, so you can look at one part of the program (say the Address class) without having to read all code it depends on.

For example I'm sure you don't yo-yo into reading the source code for String every time you encounter String in code.