build broken

Wir haben wie viele von uns in der Webentwicklung vor vielen Jahren mit Scriptsprachen und mit prozeduralen – Spaghetti-Code 😉 – angefangen. Mit der Zeit wuchs unsere Webpräsenz zu einer unüberschaubaren Anwendung mit manchen Seiten, die keiner von uns mehr anfassen wollte – aus Angst vor den Konsequenzen.

Um etwas Ordnung in die Webanwendungen zu bringen, haben wir also vor 4 Jahren angefangen, nach einem 3-Schichten-Modell zu entwickeln. Wir haben neue Funktionalitäten und neue Anwendungen nur noch so gebaut und wir waren für eine kurze Zeit zufrieden. Alles lief gut. Als wir den Umstieg auf .NET begonnen haben, haben wir weiterhin nach einem Mehr-Schichten-Modell gearbeitet, wir haben nur die Anzahl der Schichten erhöht.

Die Anwendungen wuchsen weiter, wir haben immer mehr Bereiche ausgelagert und diese hauptsächlich mit Webservices angesprochen. Währenddessen waren wir daran, unser Hauptprodukt, ein Portal für unseren Kunden mit der neuen Technologie entsprechend der alten Anforderung neu zu bauen. Und dann ist es passiert: ehe wir uns versahen, hatten wir ein riesiges Projekt, das alle mögliche Anwendungen eingebunden bzw. durch Webservices angesprochen hat. Die Grenzen waren fließend, eventuelle Änderungen an anderen Anwendungen konnten das Projekt unbuildbar machen, also ein ähnlicher Zustand wie vor paar Jahren zuvor.

Die Weiterentwicklung hat nicht nur in unserer Art zu Programmieren stattgefunden, wir selbst haben uns auch weiterentwickelt, wir haben die Community kennen gelernt. Bei den Open Space-Veranstaltungen haben wir Stefan und Ralf kennengelernt und durch sie eine andere Sichtweise der Dinge: die Modellierung einer Lösung durch Softwarezellen.

Wir haben sie zu uns eingeladen und uns die Idee erklären lassen. Das Stichwort heißt Holon. Wikipedia definiert ein Holon folgendermaßen:

Der Begriff Holon (von griech. ὅλος, hólos und ὀν, on „ganzes Seiendes“) wurde von Arthur Koestler geprägt und bedeutet ein Ganzes, das Teil eines anderen Ganzen ist. Es wird auch als “Ganzes/Teil” umschrieben.

Jede Anwendung ist ein Ganzes, die aus Teilen besteht, die ihrerseits auch als Ganze zu betrachten sind.

Seit dem Besuch von Ralf und Stefan haben wir uns die Artikelserie von Ralf von dotnetpro durchgelesen, die Webcasts (Teil 1, Teil 2) angeschaut und wir haben angefangen, diese Modellierung auszuprobieren.

Wir haben noch einen langen und interessanten Weg vor uns, aber eins ist jetzt schon sicher: wir werden versuchen unsere nächste Projekte durch Softzellen modellieren.

Solange die Komplexität nicht wieder die Überhand gewinnt 😉

Der vorherige DbC-Artikel ist ziemlich “abstrakt” ausgefallen, es haben einfach Beispiele gefehlt. Das möchte ich hiermit nachholen.

Erstens muss man die IDE anpassen: im März kommt .NET 4.0 raus und da wird Design by Contract mitgeliefert. Man kann das Konzept aber jetzt schon anwenden, wenn man die Assembly zusätzlich installiert. Danach muss man die dll referenzieren und im Eigenschaftenfenster des Projektes im neuen Tab Code Contracts das Runtime Checking einstellen.

Jetzt zum Code: Nehmen wir eine ganz einfache Klasse Bill deren Objekte mit einem IRepository gespeichert bzw. geladen werden.

Die Kontrakte kann man in den einzelnen Methoden oder für eine ganze Klasse schreiben (unter dem Attribut ContractInvariantMethode) aber ich finde am schönsten, dass man die auch auslagern kann: durch eine gegenseitige Markierung können Kontrakt-Klassen und Interfaces als “Paare” definiert werden:

Eine Vorbedingung wird mit Contract.Requires und eine Nachbedingung mit Contract.Ensures definiert. Beide Methoden bekommen boolische Ausdrücke. Diese Ausdrücke müssen frei von Seiteneffekten sein.

Die eigentliche Implementierung der Klasse schaut dann so aus:

Woher können wir wissen, dass das funktioniert? Es ist einfach, wir schreiben ein Paar Tests dazu!
Bei Kontraktverletzung wird eine Exception geworfen. Um diese – und dadurch die genaue Verletzung – überprüfen zu können braucht man etwas Workaround:

Danach sind die Tests dann einfach:

Ich hoffe, das Beispiel ist ausführlich genug, um die Vorteile von DbC zu highlighten. Stefan, vielen dank noch mal für den Artikel, ich habe mich natürlich von dir inspirieren lassen.

Bald kommt .NET 4.0 raus, zusammen mit einem für C# neuen Konzept: Kontrakte im Code mit Spec# festzulegen.

Wikipedia definiert DbC folgendermaßen:

Design by contract (kurz DbC; englisch Entwurf gemäß Vertrag) oder Programming by Contract ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler „Verträge“ zur Verwendung von Schnittstellen, die über deren statische Definition hinausgehen. Entwickelt und eingeführt wurde es von Bertrand Meyer mit der Entwicklung der Programmiersprache Eiffel.

Stefan Lieser hat über das neue Konzept einen sehr guten Artikel in www.visualstudio1.de geschrieben, mit Begriffsklärung und Anwendungsbeispiele. Kurz zusammengefasst ist die Rede von Folgendem: anstelle, dass man in jeder Methode auf not-null or not-empty usw. prüft, schreibt man die Erwartungen als Code hin. Diese werden von Tools wie z.B. Resharper erkannt und bei fehlerhaften Aufruf der Methode, wird der Entwickler gewarnt. Am besten finde ich, dass man den Kontrakt-Code z.B. für einen Interface in eine separate Klasse schreiben kann und diese wird durch Attribute (ContractClassFor) gefunden. Also wird dadurch der eigentliche Code nicht größer.

Das soll nicht bedeuten, dass der Entwickler der Methode die Verantwortung von sich schiebt ;), sondern dass er Bedingungen der “Nutzung” offenlegt, Informationen, die bisher nur durch das Anschauen des Codes oder durch mündliche/schriftliche Mitteilung möglich war. Mit Spec# kann man die Intention-Revealing Interfaces ganz genau schreiben: mit veröffentlichten und kompilierten Bedingungen.

Heute habe ich einen recht interessanten Artikel gelesen. In diesem ging es darum besseren Code zu schreiben, zu warten und im allgemeinen besser mit ihm umzugehen. Die Rede ist dabei von Clean-Code-Developer.

Dabei geht es weder darum neue Technologien zu verwenden, noch darum neue Sprachen zu erlernen. Eigentlich ist es eher ein kleiner Leitfaden um sich stetig zu verbessern, und das wollen wir doch im Allgemeinen eh, sonst würde dieser Blog-Eintrag wohl auch nicht gelesen.

In meinem ersten Blog-Post möchte ich euch in vereinfachter Form meine Umsetzung des Plug-In-Patterns vorstellen.
Voraussetzungen für dieses Pattern sind:

• eine Host-Applikation die das Plug-In laden möchte
• ein Plug-In welches es zu laden gilt
• und die Schnittstellen Plugin und IHost

Zu allererst brauchen wir eine gemeinsame Schnittstelle, die sowohl vom Plug-In als auch vom Host (die Applikation welche das Plug-In verwenden soll) benutzt werden soll. Über diese Schnittstelle kommuniziert der Host mit dem Plug-In.
Es würde sich das Interface IPlugIn anbieten. In meinem Fall verwende ich allerdings kein Interface sondern eine abstrakte Klasse, da ich bereits Logik direkt in die Schnittstelle implementieren möchte. In meinem Fall heißt die abstrakte Klasse einfach nur Plugin. Im weiteren Verlauf werde ich zu meiner abstrakten Klasse Schnittstelle sagen.

    1 public abstract class Plugin {

    2     private IHost m_host;

    3     public Plugin(string name) {

    4         Name = name;

    5     }

    6

    7     public string Name { get; set; }

    8     public string Author { get; set; }

    9     public string Version { get; set; }

   10     public bool IsRegistered { get; private set; }

   11

   12     /// <summary>

   13     /// Setzt oder gibt die Host-Application.

   14     /// </summary>

   15     /// <value>Host-Application.</value>

   16     public IHost Host {

   17         get { return m_host; }

   18         set {

   19             if (value != null) {

   20                 if (m_host == null) {

   21                     m_host = value;

   22                     if (m_host.Register(this)) {

   23                         IsRegistered = true;

   24                     }

   25                 }

   26             } else {

   27                 if (m_host.Unregister(this)) {

   28                     m_host = value;

   29                     IsRegistered = false;

   30                 }

   31             }

   32         }

   33     }

   34 }

Ich glaube, der Aufbau der Schnittstelle Plugin sollte bis auf die Property “Host” klar sein. Wie man sieht, benötigt man bei diesem Pattern zusätzlich zur Schnittstelle Plugin noch das IHost-Interface.
Dieses Interface ist direkter Bestandteil der Schnittstelle Plugin. Nun kann man sich natürlich die Frage stellen, warum das Plug-In den Host kennen muss und somit von diesem abhängig ist.

Zum einen ist es in der Regel so, dass ein Plug-In für nur einen Host entwickelt wird und zum anderen wollte ich dem Host gewisse Richtlinien zum Registrieren und Lösen des Plug-Ins vorgeben.

Das Interface IHost sieht folgendermaßen aus:

    1 public interface IHost {

    2     bool Register(Plugin plugin);

    3     bool Unregister(Plugin plugin);

    4 }

Dieses Interface muss von der Host-Applikation implementiert werden, damit sich das Plug-In am Host registrieren kann. Im letzten Satz habe ich es schon angedeutet. Nicht der Host registriert das Plug-In bei sich, sondern das Plug-In registriert sich am Host. Durch das setzen der Property Plugin.Host wird die Methode Register oder Unregister vom Plug-In aufgerufen, welche der Host implementiert.

Eine vereinfachte Darstellung der Implementierung des IHost -Interfaces sieht folgendermaßen aus:

    1 public class HostApplication : IHost {

    2     private List<Plugin> m_pluginList;

    3

    4     //Konstruktor

    5     public HostApplication() {

    6         m_pluginList = new List<Plugin>();

    7

    8         //Lädt alle verfügbaren Plug-Ins zb. aus einem Verzeichnis

    9         List<Plugin> plugins = GetPlugins();

   10         foreach (Plugin plugin in plugins) {

   11             //ruft implizit die IHost.Register-Methode auf

   12             plugin.Host = this;

   13         }

   14     }

   15

   16     public void ShowPlugins() {

   17         foreach (Plugin plugin in m_pluginList) {

   18             //Ausgabe der Namen aller am Host registrierten Plug-Ins

   19             Console.WriteLine(plugin.Name);

   20         }

   21     }

   22

   23     public void UnloadPlugins() {

   24         foreach (Plugin plugin in m_pluginList) {

   25             //ruft implizit die IHost.Unregister-Methode auf

   26             plugin.Host = null;

   27         }

   28     }

   29

   30     #region IHost-Implementierung

   31     public bool Register(Plugin plugin) {

   32         if (!m_pluginList.Contains(plugin)) {

   33             m_pluginList.Add(plugin);

   34             return true;

   35         }

   36         return false;

   37     }

   38

   39     public bool Unregister(Plugin plugin) {

   40         if (m_pluginList.Contains(plugin)) {

   41             m_pluginList.Remove(plugin);

   42             return true;

   43         }

   44         return false;

   45     }

   46     #endregion

   47 }

Das Registrieren und Lösen der Plug-Ins könnte man nun noch in einen Plug-In-Manager auslagern, worauf ich in diesem Blog allerdings verzichten möchte.