Dienstag, 24. August 2010

CCD Prinzipien außerhalb der Galerie

Die Menge guter Prinzipien für die Entwicklung objektorientierter Software ist groß. Im Kontext von CCD sind die wesentlichen Prinzipien bereits formuliert worden. Im folgenden Bericht werden weitere Prinzipien genannt, die zu der Menge von CCD Prinzipien gehören.

Acyclic Dependencies Principle (ADP)
ADP behandelt das Deployment von Applikationen und deren Paketabhängigkeiten.

ADP ist aus Sicht des Deployments anzustreben. Softwarepakete sollen wiederverwendbar und wartbar sein, sowie das Klassendesign sind auch Paketstrukturen zu entwerfen. Die Paketstrukturen dürfen nur definierte Abhängigkeiten aufweisen, sodass sie leicht deployed werden können.

ADP Kernaussage: Die Abhängigkeitsstruktur zwischen Paketen muss ein "Directed Acyclic Graph (DAG)" sein.

DAG sagt aus, dass bei der Paketnavigation kein Pfad ein Paket mehr als einmal enthalten darf. Warum? Der einfachste Zyklus bedeutet, dass Paket "A" von Paket "B" abhängig ist, welches wieder von Paket "A" abhängt. Dies führt zu falschen Klassenabhängigkeiten und erschwert das Deployment.

Zyklische Abhängigkeiten entstehen wenn unterschiedliche Entwickler an dem gleichen Paket oder Klasse arbeiten. Ein Zyklus kann mit dem Dependency Inversion Principle (DIP) gebrochen werden.

Paketstrukturen sind früh im Entwicklungsprozess zu entwerfen. Pakete folgen den Paketkonventionen (Namensregeln), sodass Probleme während der Entwicklung und des Deployments vermieden werden.

Common Closure Principle (CCP)
CCP ist ein Paketentwurfsprinzip, dass die Wartbarkeit von Softwarepaketen fördert.

Das Common Closure Principle rät, dass Klassen die zusammengehören in demselben Paket verwaltet werden. Die Zusammengehörigkeit von Klassen ist dabei ausgehend von der Änderungs- und Verteilungsperspektive zu betrachten.

Klassen, die gemeinsam geändert werden, sind in demselben Paket zu verwalten. Eine Änderung, welches das Paket betrifft, tangiert auch die Klassen des Paketes.

Common Reuse Principle (CRP)
CRP bildet eine gute Grundlage für das Zusammenfassen von Klassen und Paketen.

Beim Entwurf von Paketstrukturen ist die Entscheidung, welche Klassen in einem Paket zusammengefasst werden sollen, essentiell.

Die korrekte Bündelung von Klassen vermeidet ungewollte Abhängigkeiten und vereinfacht aus Benutzersicht die Anwendung von Softwarepaketen.

CRP sagt aus, dass nur Klassen mit Kohäsion zusammen in einem Paket gebündelt werden sollen. Die Bündelung und Kohäsion der Klassen ist dabei aus der Benutzerperspektive zu sehen. Falls ein Benutzer ein Paket verwendet, sollen alle Klassen des Paketes im Benutzerkontext wiederverwendet werden können.

Anwendungsegel: Alle Klassen einer gemeinsamen Funktionalität, sollen in demselben Paket hinterlegt werden.

Die vorstehenden Prinzipien (ADP, CCP und CRP) sind von Object Mentor Incoporated und Robert C. Martin formuliert worden. Object Mentor Incoporated hält alle Rechte an den genannten Prinzipien!

Principle of API Design (PAD)
PAD ist primär für die Framework-Entwicklung gedacht, bei der öffentliche APIs entstehen, die bedingungslos nachhaltig sein müssen.
 
Eine API wird oftmals überladen, um die Anforderungen von "Jedermann" zu erfüllen. Dabei wird bei der Konzeption und Entwicklung der API der spätere Verwender nur geringfügig involviert. Beim Entwurf der API beeinflussen technische Strukturen und Implementierungsdetails das API-Design. Die Anforderungen an eine API sind oft nicht detailiert genug und zeitlich einordenbar, sodass das API-Design nicht nur die Gegenwart fokussiert, sondern bereits mögliche Anforderungen der Zukunft berücksichtigt. Diese Gründe beeinflussen in negativer Weise die Softwarequalität einer API, deren Anwendungsmöglichkeiten und Nachhaltigkeit.

PAD definiert deshalb die folgenden Kriterien für das API-Design:

1. Eine API ist Korrekt und vollständig, konform der zu erfüllenden Anforderungen.

2. Die API ist einfach anzuwenden, zu lernen, zu erweitern und zu warten. Die API begegnet der Falschanwendung mit definierter Robustheit.

3. Die Implementierung der API darf die API selbst nicht beeinflussen. Änderungen in der Implementierung dürfen keine Auswirkung auf die API haben.

Clean Code Developer befolgen PAD um die Güte einer API zu verbessern:

1. Es werden nur die Anforderungen in die API übernommen, die tatsächlich benötigt werden – When in doubt, leave it out! (Joshua Bloch).

2. Die API wird aus Sicht des Verwenders implementiert und ab dem frühen Entwicklungsstadium in iterativen Zyklen vom Verwender geprüft.

3. Die API verbirgt Implementierungsdetails, reagiert bei Falscheingaben gutmütig mit definierten Fehlermeldungen und minimiert die Zugriffsmöglichkeiten auf die zugrundeliegende Implementierung.

4. Validierungen und mögliche Fehlerfälle werden möglichst früh in den oberen Schichten der API behandelt.

5. Die API beinhaltet aussagekräftige Namen, ist gut dokumentiert und verhält sich, wie man erwarten würde.

PAD wurde durch einen Vortrag von Joshua Bloch über das Thema API Design inspiriert und in Kombination mit den Erfahrungen in der objektorientierten Softwareentwicklung des Blogbetreibers formuliert.

Principle of Implementation (POI)
POI bezieht sich auf die Implementierung einer Software und deren Quellcodestruktur. POI empfiehlt Muster und Idiome bei der Programmierung anzuwenden, um bewährte Implementierungstechniken wiederzuverwenden.

Die Anwendung von POI soll den Änderungsaufwand für neue Funktionalitäten gering halten und die Softwarequalität nachhaltig verbessern.

POI konformer Quellcode beinhaltet die folgenden Strukturmerkmale:

1. Änderungen des Quellcodes wirken sich nur lokal aus, um Seiteneffekte zu vermeiden. Grundsätzlich ist beim Schreiben des Quellcodes die vertikale Trennung zu beachten, sodass Variablen und Methoden nahe bei ihrem Anwendungsort definiert werden.

2. Der Quellcode enthält keine Duplikate (DRY).

3. Daten, Programmlogik und Funktionalitäten, die sich gleich schnell ändern, befinden sich in unmittelbarer nähe zueinander. Programmlogik und Daten sollen wenn möglich in derselben Methode, wenigstens in demselben Objekt, zumindestens aber im selben Paket implementiert werden.

4. Im Quellcode sind symmetrische Strukturen zu erkennen. Eine Collection-Klasse, die über eine add()-Methode verfügt, bietet auch eine remove()-Methode an.

5. Der Quellcode drückt die Absicht des Autors klar und unmissverständlich aus. Wohlstrukturierter Quellcode lässt sich gut lesen und benötigt nur für öffentliche Schnittstellen und besonders hervorzuhebende Algorithmen einen Kommentar. Wird ein Kommentar geschrieben, soll er gut formuliert und aussagekräftig sein.

6. Stukturierter Quellcode beinhaltet bewährte Muster und Idiome. Bei der Anwendung der Muster ist zu beachten, dass diese nur dann eingesetzt werden, falls sie ihren Zweck erfüllen. Die Einfachheit einer Softwarelösung (KISS) darf nicht, durch den unzweckmässigen Einsatz der Muster, verloren gehen.

POI wurde von dem Blogbetreiber formuliert und basiert auf dessen Erfahrungen in der objekt-orientierten Softwareentwicklung.