Posts tagged ‘DSL’

Klassen und Methoden im Wandel

Als ich studierte gab es genau eine Art, Klassen und Methoden zu benennen: Klassen wurden mit Substantiven benannt, die direkt dem ungesetzten Konzept bzw. ihrer Verantwortlichleit entsprechen sollten, z.B. Auftrag. Bei den Methoden wurde streng zwischen Funktionen und Prozeduren unterschieden. Funktionen liefern Werte und lassen den Objektzustand schön in Ruhe, während Prozeduren den Objektzustand ändern und keinen Rückgabewert haben. Ob etwas Funktion oder Prozedur ist, sollte nicht nur an der Signatur deutlich werden, sondern auch im Namen. Prozeduren werden immer in Befehlsform geschrieben (z.B. berechneSumme) während Funktionen eine Substantivform bekommen (ggf. mit einem ‘get’ als Präfix, z.B. ‘getNummer’). Diese ganze Konzeption wurde z.B. von Bertrand Meyer vertreten und auch gut begründet:
Wenn man eine Klasse sucht, kann man sie leicht anhand ihres Namens finden. Und wenn man dann das API der Klasse liest, ist gleich klar, was die Methoden tun. Insbesondere ist klar, ob eine Methode nur einen Wert liefert oder ob sie gefährlich den Objektzustand manipuliert.

In den letzten Jahren hat sich an verschiedenen Stellen ein deutlich anderer Programmierstil entwickelt. Der primäre Fokus hat sich gewandelt. Es geht nicht mehr primär darum, dass man das API einer Klasse leicht lesen und verstehen kann. Stattdessen soll der Klientencode möglichst gut lesbar sein.

Bei der Benennung von Unit-Tests findet sich eine zarte Andeutung in diese Richtung. Statt AuftragTest.testSummenberechnung findet man heute immer häufiger AuftragTest.berechnetSummeDerPositionen. Die zweite Variante lässt sich als Spezifikation lesen “Auftrag berechnet Summe der Positionen”.

Noch deutlicher wird es, wenn man sich Behaviour Driven Development (BDD) ansieht.

Schließlich nutzen die Fluent Interfaces dieses Konzept auch außerhalb des Testens bzw. Spezifizierens für Produktivcode.

Aus


TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock);

wird


TimeInterval meetingTime = fiveOClock.until(sixOClock);

Für viele Entwickler, die schon länger im Java- oder C++-Geschäft sind, sind diese fließenden Interfaces sehr gewöhnungsbedürftig. Allerdings wird eine Klasse viel häufiger eingesetzt als gelesen. Also scheint es nicht gerade abwegig, mehr Gewicht auf die Benutzbarkeit als die API-lesbarkeit zu legen.

Trotzdem wird man absehbar wohl nicht alle Klassen mit einem Fluent Interfaces versehen. Dazu ist der Aufwand zu groß. Aber bei den Klassen, die sehr häufig benutzt werden, sind Fluent Interfaces sicher eine Überlegung Wert.

Nachtrag: Ein Beispiel für ein Fluent Interface findet sich z.B. in Hibernate, wenn man eine Criteria zusammenbaut.

October 6, 2007 at 1:11 pm Leave a comment

Buchtipp: Practical Common Lisp

Peter Seibel führt mit Practical Common Lisp anhand praktischer Beispiele (Unit-Testing, MP3-Dateiparsing, Web-Anwendungen etc.) in Common Lisp ein und zeigt damit eindrucksvoll, dass Common Lisp keineswegs auf künstliche Intelligenz oder funktionale Programmierung beschränkt ist.
Das Buch gehört zu den sehr wenigen IT-Büchern, bei denen das Lesen Spaß macht.

Auch wenn man selbst nicht mit Common Lisp arbeiten wird, öffnet das Buch ganz neue Perspektiven. Es ist schon erstaunlich, wie weit Common Lisp seiner Zeit voraus war und noch ist. Ich kenne keine andere Programmiersprache, die so mächtige Features hat wie Common Lisp.

Das Macro-System (nicht zu vergleichen mit dem C-Macros) erlaubt die Definition eigener Sprachen in Common Lisp – ein Ansatz, der heute als DSL (Domain Specific Language) bekannt ist und mit vergleichsweise wahnsinnig hohem Aufwand und Code-Generierung betrieben wird.

So kann man eigentlich bei jedem Feature anderer Programmiersprachen sagen: “Das hat Common Lisp auch, nur mächtiger und flexibler.” Da stimmt es mich schon etwas traurig, dass sich Common Lisp nicht in der Breite durchgesetzt hat und man heute noch mit vergleichsweisen Krücken unterwegs ist.

Da drängt sich natürlich die Frage auf, warum wir dann nicht einfach alle in Common Lisp programmieren. Eine Antwort gibt Paul Graham.

Dem habe ich noch hinzuzufügen, dass Common Lisp zwar unbestreitbar sehr mächtig ist, aber auf eigenartige Weise etwas schief zusammengesetzt wirkt. Das ist aber kein wirklich starkes Argument, weil mit Scheme und NewLisp weitere Lisp-Dialekte zur Verfügung stehen.

March 6, 2007 at 7:07 pm 1 comment

Martin Fowler: Introduction to Domain Specific Languages

Bei InfoQ gibt es die Präsentation “Introduction to Domain Specific Languages” von Martin Fowler. Hier erläutert Martin Fowler nicht nur, was eine Domain Specific Language (DSL) ist, sondern auch, wie man schrittweise zu seiner eigenen DSL kommt.
Er beginnt dabei mit XML zur Darstellung der DSL, kommt dann aber zu dem Schluss, dass XML häufig nicht die beste Darstellungsart ist. Es i.d.R. gibt deutlich kompaktere Schreibweisen, die den Umgang mit der DSL erheblich vereinfachen können. Ähnliche Gedanken scheinen auch die Spring-Macher umzutreiben.

December 3, 2006 at 6:05 am Leave a comment

DSL: Domain Specific Languages

Martin Fowler hat einen kurzen Artikel über DSLs in seinem Blog veröffentlicht. In dem Artikel erklärt er den Unterschied zwischen General Purpose Languages (GPL) und DSLs. Außerdem argumentiert Fowler, dass der Übergang zwischen APIs und DSLs fließend ist. Das API einer Bibiothek könne durchaus vergleichbar sein mit einer DSL.

Das finde ich sehr überzeugend, vor allem wenn man sich die dynamischen Skriptsprachen a la Ruby, Groovy oder Lisp ansieht. Dort wo in Java eigene DSLs für Build-Skripte (ANT), Datenbankabfragen (Hibernate Query Language, HQL) oder Oberflächenbeschreibung (HTML, JSP) verwendet werden, haben Ruby und Konsorten einfach nur Bibiotheken, die innerhalb der Programmiersprache verwendet werden.

Interessant finde ich, dass alle Artikel zum Thema DSL, die ich kenne (ich gebe zu, dass das nicht allzu viele sind), sich ausschließlich um Technologie-Domänen kümmern. Es kommen immer wieder dieselben technischen Beispiele für DSLs: SQL, ANT, etc. Das finde ich schade. Schließlich sind die technischen Aspekte in einem Softwareprojekt eher uninteressant im Gegensatz zu den fachlichen. DSLs nur für technische Aufgaben zu verwenden, riecht nach einer Optimierung an der falschen Stelle (wenn ich in einem Bereich 50% Aufwände spare, der nur wenige Prozent meiner Gesamtaufwände ausmacht, ist der Gesamtgewinn marginal).

Eigentlich müssten wir nach fachlichen DSLs suchen. Interessiert das Niemanden, ist das so schwer oder lese ich einfach nur die falschen Quellen?

August 4, 2006 at 10:37 am Leave a comment