Ich möchte mich ein wenig über Dinge unterhalten, über die Entwickler normalerweise nicht unbedingt gerne reden: Über Ängste. Es hört sich vielleicht etwas komisch an, aber auch Entwickler müssen sich in ihrer täglichen Arbeit ihren eigenen Ängsten stellen. Z. B. beim entwickeln und konzipieren von objekt-orientierter Software.

Es gibt viele verschiedene “Ängste”, denen man beim programmieren von OO-Software entgegnen kann. Diese Ängste lassen sich im Übrigen relativ gut aus dem Code “herauslesen”.

Eine der oftgesehendsten Ängste in der OO-Programmierung ist die Angst vor Logik. Im OO-Design spiegelt sich das relativ deutlich wider, wenn man viele verschiedene Klassen und Objekte hat, die sich um eine zusammenhängende Aufgabe, einen bestimmten Datensatz oder ein bestimmtes Objekt kümmern.

Ein Beispiel soll das Ganze etwas verdeutlichen:

public class Credentials
{
  private string username;
  private string password;

  public Credentials()
  {
  }

  public string UserName
  {
    get { return this.username; }
    set { this.username = value; }
  }

  public string Password
  {
    get { return this.password; }
    set { this.password = value; }
  }
}

Auf den ersten Blick mag man annehmen, die Klasse sei ein einfacher Datencontainer (DTO). Dem ist jedoch nicht so. In Wahrheit ist die Klasse eine Business Entity ohne Logik. Die Logik ist einfach in anderen Klassen, wie z.B. in solch einer:

public static class CredentialsUtility
{
  public static bool Validate(Credentials credentials)
  {
    if (credentials != null)
    {
      return !String.IsNullOrEmpty(credentials.UserName);
    }

    return false;
  }
}

An diesen zwei Klassen wird deutlich, das der Entwickler eine höllische Angst gehabt haben muss, das Business Entity mit Logik anzureichern. Denn i.d.R. ist es genau die Aufgabe eines Business Entities, diese Logik (z.B. Validierung) zu kapseln. Meiner Meinung nach ist diese “Angst” völlig unberechtigt und für ein kohärentes OO-Design kontraproduktiv. Fakt ist zudem, das es zur fundamentalen Schule der OO-Programmierung gehört, Klassen mit eindeutigen Verantwortlichkeiten zu schaffen.

Natürlich muss im Einzelfall geprüft werden, welcher Grad der Kohäsion für die Anwendung und die Architektur geeignet erscheint. Prinzipiell sollte man jedoch ein gutes Mittelmaß zwischen Kohäsion und Kopplung anstreben. Komponentenorientierung und lose Kopplung ist sicherlich wichtig. Auf der Ebene der Anwendungslogik respektive Business Entities sollte man meines Erachtens tunlichst zusammenhängende Logik in die Klasse zu kapseln.

Mein Fazit: Keine Angst vor Logik! Anwendungslogik gehört in die Anwendungsklassen und muss nur dann verteilt werden, wenn es wirklich notwendig ist.