Softwareprogrammierung & ´The lost architecture` by Robert C. Martin

In der Softwareprogrammierung ist Robert C. Martin einer der bedeutensten Köpfe. Oliver Noth, Softwareentwickler der secu-ring GmbH fasst in dieser Keynote die wichtigsten Stichpunkte über Robert C. Martin zusammen.

Steckbrief: Robert C. Martin (Uncle Bob):

  • Programmierer seit 1970
  • Schrieb verschiedene (manche sagen: bahnbrechende) Bücher zu den Themen: Softwareprogrammierung, UML, OOP, C++ – Programmierung
  • Wird heute als eine der führenden Kapazitäten in der agilen Softwareprogrammierung angesehen
  • Zitat: Glaube nicht, dass Du unersetzlich bist, nur weil Du gut bist („Doctor House is a looser“)

Seine Standpunkte:

Web

Es hat uns blind gemacht und wir machen es zur zentralen Abstraktionsebene unserer Webapplikation. Wir sollten es als eine der verfügbaren Infrastrukturen verstehen. An unseren Applikationsarchitekturen soll man den Zweck der Applikation ablesen können, nicht die Infrastruktur, innerhalb derer die Applikation läuft.

Use Cases

Anstatt sich auf diese Infrastruktur zu konzentrieren, schlägt er vor, Objekte zu benutzen, die den jeweiligen Use Case 1:1 widerspiegeln. Er nennt diese Objekte INTERACTORS. Diese Objekte sind KEINE MVC-Controller. In ihnen sollte unabhängig vom jeweils verwendeten Framework die komplette Businesslogik abgebildet werden.

Entities

Diese Business Objekte enthalten die Daten und operieren mit ihnen. Sie sind KEINE MVC-Models. Sie sind komplett entkoppelt von der Datenstruktur und anderen Anwendungskomponenten.

Boundaries

Sie sind die Schnittstellen zur jeweiligen Infrastruktur. Beispiel Web: Aus dem http-Request erzeugt die Boundary ein Request-Objekt. Lediglich eine Datenstruktur mit Inhalten (keine Methoden, etc.), die keinerlei Hinweis auf die zugrunde liegende Infrastruktur enthält.

Result Model

Auch das Result Model ist lediglich eine ‘dumme’ Datenstruktur, die der INTERACTOR nach Verarbeitung des Request-Objekts bereitstellt. Nach Weitergabe an die Boundary bleibt es der dahinterliegenden Schicht (er nennt sie DELIVERY MECHANISM) überlassen, wie weiterverfahren wird: Anbieten als Web Service, Darstellung als Website, etc.

MVC

Das MVC war und ist nicht gemeint als Architektur-Pattern, sondern es ist ein kleines Design-Pattern, das mehrfach benutzt werden kann. Beispiel: Eine MVC-Instanz für den Fenstertitel, eine für den Schliessen-Button, eine für die Scrollbar usw. In Webanwendungen hat sich leider die Benutzung EINER MVC-Instanz für den kompletten Screen durchgesetzt. Auch schlecht in diesem Zusammenhang: Das View-Objekt benutzt sehr oft Model-Objekte auf
direktem Weg, obwohl das View-Objekt vom Model gar nichts wissen dürfte. Das zu umgehen, schlägt er die Anwendung des Presenter-Patterns vor: Ein View-Model nimmt das Response-Model entgegen, so dass das View die darzustellenden Daten vom View-Model entgegennimmt.

Datenbank

Leider nimmt die Datenbank mit dem von ihr benutzten DBMS einen sehr zentralen Platz in der Abstraktion der meisten Web-Applikationen ein. Die jeweilige Ausprägung der Datenhaltung (Datenbank DBMS, Dateistruktur, XML, etc.) sollte von der Applikation entkoppelt werden: Durch das bereitstellen einer Schnittstelle, die die Datenoperation übernimmt und somit eine Unabhängigkeit der Applikation von der Ausprägung der Datenhaltung herstellt.

Schluss

Es geht im wesentlichen um die Abgrenzung und Abhängigkeiten innerhalb der Applikation: Ein Bild, in dem die einzelnen Teile durch Linien voneinander getrennt sind. Wenn man es schafft, Abhängigkeiten der Teile über diese Linien nur in eine Richtung laufen zu lassen, so hat man einen Edelstein geschaffen.

Quellenangaben:

http://en.wikipedia.org/wiki/Robert_Cecil_Martin
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.