Schnittstellen - Ein pragmatischer Ansatz

Heute will ich mal versuchen zu erklären, wie ich schöne Schnittstellen entwerfe. Natürlich gelingt es mir nicht immer, aber ich tue mein bestes. Dennoch empfinde ich es als eine der schwierigsten Disziplinen in der Softwaretechnik, aber wem sage ich das, ihr werdet bestimmt auch Tag für Tag Interfaces entwerfen.

Es gibt die klassische Methode sowas zu erledigen. Ab ans Reißbrett und ein schönes UML-Diagramm gezeichnet. Das ist eine schöne Möglichkeit schon mal alle Komponenten zu skizzieren. Finde ich eigentlich eine gute Vorgehensweise, nur leider fehlt mir dabei irgendwas. Solche Diagramme sind einfach sehr theoretisch und kühl, ich kann nicht sagen, ob sich das Resultat gut „anfühlt“. Klingt jetzt recht subjektiv für eine objektive Welt, wie wir sie eigentlich als Informatiker gewöhnt sind. Interfaces müssen sich aber gut anfühlen, damit man gerne damit arbeitet.

So jetzt nehmen wir mal meine Vorgehensweise, ob sie einem gefällt oder nicht ist, denke ich, Geschmackssache. Ich fange einfach an mit einer leeren Seite PHP-Code. Dann tue ich so, als ob ich meine Klassen schon hätte und programmiere ein einfaches Beispiel. Während ich dann so Pseudocode verfasse, formen sich die Schnittstellen automatisch. Wenn ich dann mein Beispiel fertig habe, habe ich auch die meisten öffentlichen Methoden, die ich brauche.

Jetzt kommt natürlich der Schritt, wo man – falls es was wichtiges ist – das ganze von einem Kollegen reviewen lässt. Aber ich denke, das man meistens mit so einem Start eine saubere Schnittstelle hinbekommt. Jetzt kann man sich immer noch hinsetzen und UML-Diagramme zeichnen. Da man aber schon mit der Klasse gearbeitet hat, weiß man jetzt auch wie sie sich anfühlt. Joa, das ist zumindest eine Art, wie ich Klassen und Komponenten entwerfe. Ich bin sicher, jeder von euch hat eine eigene Methode um Interfaces zu bauen, vielleicht hat ja auch einer Lust seine Rangehensweise kurz zu erklären.

Ein Kommentar

Die Methode ist mir auch bekannt, als ich noch wenig Ahnung hatte von OOP, hab ich meine einfachen Klassen so gebaut, das sie in der Praxis schlicht und einfach anwendbar sind. Also wurde auch eine PHP-Datei angelegt, oder schon in der Produktivseite, und dann wurde losgeschrieben. Am Ende wurde die Klasse nach den Anforderungen geschrieben, fertig.

Momentan ist es eigentlich genauso, nur das ich jetzt anfange die Klassen zu entwerfen und mir im Kopf zu überlegen, was passt dazu, welche methoden brauch man wirklich, welche davon sind public/private/protected. Sollte man mehrere anstatt nur eine Methode für diese Logik schreiben, Entwurfsmuster…
Was hat alles dazu kommt.

Ansonsten bin ich mit deiner genannten Methode auch recht gut gefahren.

Gruß,
Steven

Klingt sehr danach, als würde man einfach Use-Cases entwerfen. Das gibs übrigens auch in UML, falls ein „der pragmatische Ansatz“ zu unsystematisch erscheint.

Ich verbinde das meistens direkt mit dem Erstellen von Unit Tests.
So schreibe ich Use Case und Test Case zur gleichen Zeit.
Klappt ganz gut muss ich sagen.

Gruß,
Patrick

Deine pragmatische Methode kommt mir recht bekannt vor. Ich verfolge einen ähnlichen Ansatz und füge noch eine „Priese“ testgetriebene Entwicklung hinzu, d.h. meine Beispiele sind Unit Tests. Ich finde es auch immer wichtig, dass sich eine Schnittstelle „gut anfühlt“.

Vielleicht noch einen Schritt weiter ist François Zaninotto gegangen.

Er hatte vor ca. 2 Jahren eine Praesentation zum Thema Documentation Driven Development (DDD) gehalten.
http://redotheweb.com/2008/09/15/developing-for-developers-my-symfonycamp08-presentation/

Das ganze ist recht dbFinder zentrisch. Den Ansatz fand ich damals aber gar nicht schlecht.

Eigentlich müsste ich jetzt ja „so ein Blödsinn“ schreien! Informatik ist eine Ingenieurswissenschaft. Und ein Architekt setzt sich auch ans Reißbrett und plant sein Haus *bevor* er beginnt den Keller zu bauen.

In der Praxis funktioniert aber erfahrungsgemäß Softwareentwicklung bzw. Softwarearchitektur nur recht selten so (zumindest bei kleinen bis mittleren Projekten). Vor allem in der Implementierung von Web-basierter Software, wo der Deploymentteil oft nur noch aus einem Mausklick besteht. Insofern würde ich sagen, dass dein Ansatz durchaus nachvollziehbar ist.

Aber spätestens, wenn man in einem Team von mehreren Dutzend Programmierern arbeitet sollte man den Ansatz schleunigst vergessen ;-).

@Christian: Wenn du schon mit Architekten und Ingenieuren anfängst… 😉
Auch die testen neue Konzepte erstmal in kleinem Maßstab. Wenn das Modell der Brücke zusammen fällt, muss eben was neues her. Auch bei Teams mit vielen Entwicklern, gibt es immer wieder mal „Proof-of-Concepts“. Lösungen zu bekannten Problemen muss man auch nicht erst durchspieln, die kann man dann designen.

So etwas geht bei mir selten gut, diese Methode verwende ich wenn etwas schnell fertig werden muss.

Ansonsten ist es eher so, das ich mir schon Tage/Wochen vorher Gedanken darüber mache, was ich brauche. Die Umsetzung wird meistens „blind“ aus dem Kopf herunterprogrammiert, erst wenn alles fertig ist wird angefangen zu testen. Anschließend werden hier und da Feinschliffe bezüglich Performance gemacht.

DDD gibt es bei mir (leider) nicht in Wirklichkeit, die Theorie möchte es zwar gerne, aber genauso wie beim TDD ist die Zeit dafür oft leider nicht vorhanden.

@Juan – Ja in der Theorie, finde ich TDD auch ganz toll und klingt viel versprechend, nur leider sehen das viele Kunden (gerade bei kleineren Projekten) einfach nicht so, da der mit zubezahlende Zeitfaktor vom Kunden oft einfach nicht „gefressen“ wird, so bleibt es denn oft wirklich bei einer sehr pragmatischen und etwas fehleranfälligeren Programmierung… 🙂

Die Methode nutze ich auch des öfteren besonders wenn ich sonst gerade keine Lust habe von Grund auf nur mit UML zu arbeiten.

Diese Methode habe ich selbst oft und gerne angewendet. Damit werde ich aber nur dann glücklich wenn ich das Einsatzgebiet (die späteren Anwendung) kenne. Bei Services im Internet oder bei Basiskomponenten ist das nicht so. Da braucht man schon ein paar Diagramme, Szenarien und viel Erfahrung. Stellt euch mal vor Zend_Framework, JCR oder Symfony wird so entwickelt.

Also ich gehe dabei immer so vor, dass ich mir überlege welche Funktionalität brauche ich von der Schnittstelle und in welchem Zusammenhang. Also auch das ich Use-Cases durchgehe und mir dabei überlege was muss rein- und raus damit ich meine Aufgabe erfüllen kann.

Losprogrammieren klappt bei „flacheren“ Schnittstellen noch ganz gut, bei komplexeren APIs muss man jedoch schon mit Use-Cases ran, weil man so schneller alle notwendigen Fälle erwischt.

Aber das mit dem Pseudo-Code mache ich auch! =)

@Stefan

Das wäre so, als wenn ich meinem Handwerker sagen würde: „Leg die Fliesen sofort schnell und gerade auf den Boden, ein sauberer Untergrund kostet nur Zeit und Geld“.
Einem Kunden verkaufst du nicht, dass du mit TDD entwickelst und dafür extra bezahlt werden möchtest. Es ist vielmehr ein unabdingbarer Teil des Ganzen. So entwickelst du qualitativ hochwertige Software nun mal eben.

Ich unterhalte mich nicht mit meinen Kunden über meine Methodiken. Sie wollen etwas, ich gebe ihnen etwas. Wie ich das mache, ist meine Sache.
Und hat ihren Preis, natürlich.

Aber ist das in irgendeiner Branche anders?

Apropos: ist nicht eines der Hauptargumente pro TDD, dass man damit gute und saubere Schnittstellen hinbekommt (, die man vorher nicht mal erahnt hatte)? Klingt bei Nils so, als würde er TDD garnicht einsetzen…

@kingcrunch: der Unterschied zwischen dem Brückenbaubeispiel und einem Stück Software ist, dass man das Modell für die Brücke immer wegwirft, bzw. das Brückenmodell nie Teil der eigentlichen Brücke wird. Bei Software ist das meist/immer/oft anders… da ist der Prototyp früher oder später im Produkt, weil niemand den ganzen Prototyp wegwirft, bevor er mit der eigentlichen Produktentwicklung beginnt.

Dementsprechend gefährlich kann der erwähnte Ansatz sein.

Bei kleineren, einfacheren Schnittstellen finde ich den Ansatz ergänzt mit TDD sehr gut. Ich definiere direkt in den Tests meine Anforderungen und programmiere diese später bei Bedarf aus. Die Anforderungen ergeben dann inetwa die Schnittstelle.

Bei grösseren Projekten bzw. Schnittstellen ist es schwierig um eine Analyse bzw. Designphase ohne Code herumzukommen. Wenn es aber dann konkret an die Umsetzung geht, findet man häufig noch Schwachstellen bei der Analyse bzw. beim Design und muss die Schnittstelle mit ähnlichen Verfahren noch ergänzen (ja, bei grossen Teams wird der Kommunikationsaufwand dementsprechend einfach gross 🙂 )

@Don – Ich in der Regel erklärt man dem Kunden ja auch nur im groben wie entwickelt wird (außer natürlich er ist mit der Materie vertraut), sondern wie lange etwas dauert und wie teuer etwas ist… sind halt in der Regel eingefleischte Kaufleute… und wenn ich durch den Mehraufwand eine längere Entwicklungsdauer und damit auch einen höheren Entwicklungspreis aufrufen muss, wird sich (fast) jeder Kunde für einen Mitbewerber entscheiden, der nicht den Mehraufwand betreibt und damit kostengünstiger ist… So sieht nun mal leider die Realität aus, weil dem Kunden interessiert in der Regel „nur“ das Endprodukt, wie das im Hintergrund werkelt oder entwickelt wurde ist da leider nicht immer relevant…

@ Stefan

Ähm, ja, sag ich auch.
Aber kostest es denn mehr, wenn du besser arbeitest und die gleichen bzw. besseren Resultate erzielst, WEIL du TDD einsetzt?

Das ist ein immer wieder gern gebrachter Einwand: TDD kostet Zeit.
In Wahrheit kostet der Einsatz dieses und anderer Designwerkzeuge(s) (was TDD letztlich ist) weniger Zeit. Denn man entwickelt von Anfang an strukturierter und einfach besser, so dass es zu späteren Zeitpunkten keine zeitintensiven Änderungen des Design mehr bedarf.
Und man merkt häufig und schnell, dass das Drauflosprogrammieren nachträglich nur Kopfschmerzen bereitet und man dem Kunden erklären muss, warum man denn jetzt doch länger braucht.

Was ihn nämlich noch viel weniger interessiert ist, dass man später versucht irgendwelche aufgetretenen Designprobleme zu erklären. Das geht ihm dann wirklich am A**** vorbei.

Je besser die Werkzeuge insgesamt sind umso besser wird das Resultat.
Das muss nach einer gewissen Zeit dann auch garnicht mehr Zeit oder Aufwand kosten. Pfriemeln geht am Anfang immer igendwie schnell – und genauso schnell frustet es einen später. Doh echte Profis benutzen von Anfang an die richtigen Werkzeuge und erzielen bessere Resultate in der gleichen Zeit. Erfahrung natürlich vorausgesetzt, denn ein gutes Werkzeug macht noch keinen Profi.

@Don – Du hast eigentlich die Frage mehr oder weniger selber beantwortet. Es fehlt vielen (wie auch mir) einfach die Erfahrung Testgetriebene Entwicklung schnell und effizient einzusetzen… 😉 Von daher, wäre so ein Mehraufwand bei mir auch einfach durch die längere Entwicklungszeit teurer. 🙂

Wobei man auch ehrlich sein sollte und mit dazu sagen sollte, dass man auch innerhalb testgetriebener Entwicklung Schrott programmieren kann, den man schlussendlich auch in die Tonne werfen kann… 😉

@Stefan

Da muss ich Dir Recht geben…
Aber immerhin kann man sagen, es verhindert zumindest zu viel Müll.

Prinzipiell geht es mir auch nicht nur um TDD, auch jeder andere vernünftige Ansatz oder geeignetes Werkzeug kann mit enstprechender Erfahrung zu guten Ergebnissen führen.
Aber da es ja um Schnittstellen, und damit um Design einer Applikation ging, wäre das eins der sehr geeigneten Werkzeuge.

@DonZampano
»Aber da es ja um Schnittstellen, und damit um Design einer Applikation ging, »wäre das eins der sehr geeigneten Werkzeuge.

Ich habe die Erfahrung gemacht dass abstrakte Schnittstellen bestehen bleiben können, auch wenn die zugrunde liegende Klasse/Treiber gewechselt wird. Deshalb ist es schon wichtig, nicht nur danach zu gehen wie „es sich anfühlt“, sondern darauf zu achten, dass keine Redundanzen und Abhängigkeiten unbeachtet bleiben. Da wären wir aber dann wieder bei TDD das ganze geht im Kreis ^^