Samstag, 6. Mai 2017
Worum geht es bei der verschachtelten Modularität?
iuzuz, 22:48h
Stellen Sie sich folgendes vor. Sie kommen als Entwickler in ein schon etwas länger laufendes Projekt und versuchen nach einiger Einarbeitung in den Quellcode eine Erweiterung zu implementieren. Oft ist es so, dass man vor einem Meer von Klassen und anderen Quellcodeeinheiten steht. Mann muss 1. die richtige Stellen und 2. die richtigen Objekte und Helfer die für die Implementierung finden. Um effizient voran zu kommen, hilft einem dabei fast nur Know-How, welches meist nur in den Köpfen anderer ist.
Stellen Sie sich außerdem vor, sie wollen Test-Driven-Development betreiben. Sie wollen viele schnelle und sinnvolle Tests schreiben.
Für beide Fragestellungen - im Meer vom Code zurecht zu kommen und testbaren Code zu schreiben - wünsche ich mir eine bessere Sprachunterstützung. Modularität ist da ein guter Helfer. OSGI und Jigsaw sind in aller Munde. Das Konzept der Modularität kann aber noch verbessert werden. Ich wünsche mir Module auf der Ebene von Packages oder noch kleiner, die man verschachteln kann.
Wie kann man verschachtelte Modularität in einer Programmiersprache abbilden? Ich plädiere für ein Konzept von - ich nenne sie mal - Systemklassen: eine Art Zwitter zwischen der klassischen Klasse und Package. Eine Systemklasse kann Teilklassen beinhalten und benötigt für seine Arbeit Abhängigkeiten.
Untersysteme sind in der Regel nach außen nicht sichtbar. Es währe angebracht, diese in unterverzeichnissen zu halten. Ein System ist also auch eine Art Package, ein Behälter in dem andere Systeme "wohnen". Auf der Ebebe von Instanzen ist eine Verschachtellung sogar noch wichtiger. Eine Systeminstanz kann als Teile Untersysteme (Instanzen) haben. Deren Typ kann entweder eine Teilsystemklasse sein oder aber mit public deklarierte andere Systemklassen.
Damit ein System instanziiert werden kann, benötigt dieser Abhängigkeiten und Konfiguration. Die Systeme sollte man sich tatsächlich verschachtelt vorstellen - Teilsysteme Befinden sich _in_ dem umgebenden System. Jede Kommunikation jedes Teilsystems mit der Außenwelt erfolgt durch die "Wand" des umgebenden Systems. Die Außenwelt muss nicht wissen ob sie mit einem Teilsystem "redet". Für die Abhängigkeiten bedeutet das Folgendes. Beim Instanziieren verlangt das Umgebende System alle eigene Abhängigkeiten aber auch alle Abhängigkeiten der Teilsysteme. Mehr dazu in den nächsten Beiträgen.
Es folgt ein Vorschlag für eine konkrete Syntax, mit Begründung für einige Designentscheidungen und warum ich finde, dass damit die anfangs genannte Ziele erreicht werden.
Ich würde mich sehr für deine Meinung zu der Idee interessieren. Besonders wenn Du bereits Erfahrung mit TDD sammeln konntest.
Es ist mein erster Blog, ich hoffe es gefällt Dir :)
Stellen Sie sich außerdem vor, sie wollen Test-Driven-Development betreiben. Sie wollen viele schnelle und sinnvolle Tests schreiben.
Für beide Fragestellungen - im Meer vom Code zurecht zu kommen und testbaren Code zu schreiben - wünsche ich mir eine bessere Sprachunterstützung. Modularität ist da ein guter Helfer. OSGI und Jigsaw sind in aller Munde. Das Konzept der Modularität kann aber noch verbessert werden. Ich wünsche mir Module auf der Ebene von Packages oder noch kleiner, die man verschachteln kann.
Wie kann man verschachtelte Modularität in einer Programmiersprache abbilden? Ich plädiere für ein Konzept von - ich nenne sie mal - Systemklassen: eine Art Zwitter zwischen der klassischen Klasse und Package. Eine Systemklasse kann Teilklassen beinhalten und benötigt für seine Arbeit Abhängigkeiten.
Untersysteme sind in der Regel nach außen nicht sichtbar. Es währe angebracht, diese in unterverzeichnissen zu halten. Ein System ist also auch eine Art Package, ein Behälter in dem andere Systeme "wohnen". Auf der Ebebe von Instanzen ist eine Verschachtellung sogar noch wichtiger. Eine Systeminstanz kann als Teile Untersysteme (Instanzen) haben. Deren Typ kann entweder eine Teilsystemklasse sein oder aber mit public deklarierte andere Systemklassen.
Damit ein System instanziiert werden kann, benötigt dieser Abhängigkeiten und Konfiguration. Die Systeme sollte man sich tatsächlich verschachtelt vorstellen - Teilsysteme Befinden sich _in_ dem umgebenden System. Jede Kommunikation jedes Teilsystems mit der Außenwelt erfolgt durch die "Wand" des umgebenden Systems. Die Außenwelt muss nicht wissen ob sie mit einem Teilsystem "redet". Für die Abhängigkeiten bedeutet das Folgendes. Beim Instanziieren verlangt das Umgebende System alle eigene Abhängigkeiten aber auch alle Abhängigkeiten der Teilsysteme. Mehr dazu in den nächsten Beiträgen.
Es folgt ein Vorschlag für eine konkrete Syntax, mit Begründung für einige Designentscheidungen und warum ich finde, dass damit die anfangs genannte Ziele erreicht werden.
Ich würde mich sehr für deine Meinung zu der Idee interessieren. Besonders wenn Du bereits Erfahrung mit TDD sammeln konntest.
Es ist mein erster Blog, ich hoffe es gefällt Dir :)
... link (0 Kommentare) ... comment
