"Ich behaupte, dass man nur unter Zuhilfenahme der MPT absolut jede denkbare Software realisieren kann, egal wie komplex diese ist!"
Ziemlich gewagt, diese Aussage, oder? Gerade, wenn man bedenkt, dass es schon andere helle Köpfe gab, die sich viele Entwurfsmuster ausgedacht haben, um den heutigen Softwareproblemen Herr zu werden.
Ich sage auch nicht, dass alle Muster sinnlos sind. Im Gegenteil!
Es gibt aber eben auch Muster, welche IMHO redundant sind. Zum Beispiel gibt es da einmal den "Model View Controller" und den "Model View Presenter". Beide erfüllen unter'm Strich die selbe Funktion: Das Eine soll vom Anderen getrennt sein und dennoch hängen alle drei Elemente zusammen. Beim MVC sieht man diesen Widerspruch sehr schön.
Warum machen sich die Entwickler also das Leben so schwer?
Vom MVC gibt es zig Modifikationen, sodass man nicht sagen kann: "Ach ja, MVC! Deine Software funktioniert also so und so!" Der andere guckt dich dann verdutzt an und sagt: "Ähm ... nee, meine MVC-Variante funktioniert so und so!" ... Ach so, verstehe ... oder auch nicht. Gut, dass wir drüber geredet haben. ;-P
Bei der MPT sieht es aber anders aus! Hier ist die Spezifikation total simpel und eindeutig. Wenn ich von einem Caller-Mediator-Listener Triplet (kurz CML) rede, dann funktioniert es auch genau SO und nicht anders. Hier wird es keine Abwandlungen geben! (Ein Wassermolekül besteht schließlich auch immer aus zwei Wasserstoffatomen und einem Sauerstoffatom. Und wenn man von Wasser redet, weiß jeder, was das ist.)
Wenn ich mir überlege, dass es zu diesen diversen Pattern ganze Bücher gibt, welche diese erklären ... OMG!
Und manche Pattern sind auch nicht gerade einfach zu verstehen. (Wie will man dann erst Quellcode verstehen, welcher mit so einem Pattern realisiert ist?)
Sicher, MPT ist auch ein Muster. Aber ein sehr Einfaches, was letztlich jeder Mensch nachvollziehen kann.
Die MPT besteht nur aus drei einfachen Triplets:
Die Vorteile überwiegen die Nachteile um ein Vielfaches:
Totale Entkopplung der einzelnen Objekte!
Kein Objekt weiß von der Existenz eines anderen Objekts. Die einzelnen Objekte dürfen auch gar nichts voneinander wissen, geschweige denn direkt miteinander kommunizieren. Dies würde unweigerlich zu einer chaotischen Programmstruktur führen. Theoretisch sollte jedes Objekt völlig ohne Konstruktor-Argumente auskommen. Was ein Objekt benötigt, kommuniziert es einfach "ins Blaue" hinein. Irgendjemand wird "ihm" schon geben, was "er" verlangt (siehe CPS). Woher "er" es letztlich hat, interessiert "ihn" nicht. Die Mittelmänner (Mediator, Frequency, Provider) zählen hier ausdrücklich nicht als Objekte im oben genannten Sinne. Sie sind einfach notwendig, um die Objekte zu verbinden und dadurch Funktionalität zu gewährleisten. Man referenziert sie auch nicht, sondern sie sind einfach da.
Objekte kommunizieren vorsichtig bzw. passiv!
Das heißt, Objekte können zwar sagen, was sie wollen. Ihrem Wunsch muss aber nicht nachgegangen werden. Dadurch kann man auch mal temporär einen Kommunikationskanal unterbrechen, wenn man z.B. logische Fehler im Programm aufspüren will. Im besten Fall funktioniert dann eine Funktion nicht mehr, löst aber keine Exception aus. (Zwei Wassermoleküle kann man auch trennen, ohne dass die Welt untergeht. Bei der Software sollte es IMHO auch so sein.)
Man kann agil und flexibel seine Software entwickeln!
Schon lange vorbei sind die Zeiten, wo man vorher erstmal großartig seine Software plant. (Und das möglichst noch mit UML.) Man entwirft höchstens im Kopf mal ein grobes Konzept, wie das Gesamtbild aussehen soll.
Software darf man IMHO nicht mit einem statischen Gebäude vergleichen. Software ändert sich ständig! Da kann ich wirklich ein Lied von singen. Besonders, wenn eine recht komplexe Änderung in recht kurzer Zeit umgesetzt sein soll. (Sehr lustig wird es, wenn dann plötzlich Probleme auftreten, mit denen man gar nicht gerechnet hat.)
Mit der MPT kann man quasi die Software so entwickeln, wie sie einem der Kunde von der Funktionalität her erklärt. Einen "Button-Klick" in der Story kann man z.B. sofort mit dem CML verknüpfen, da dieser Klick irgendwas auslösen soll. Wie es weiter geht? Das kann an dieser Stelle sogar offen bleiben. Es ist wie bei einem Puzzle, wo jenes CML Triplet einen kleinen Teil vom Ganzen ausmacht. Man platziert es erstmal irgendwo und nimmt sich das nächste Puzzle-Teil her. Dies kann z.B. ein völlig anderer Aspekt sein, der mit dem "Button-Klick" gar nix zu tun hat.
Diese Freiheit hat man nur deshalb, weil alle Triplets atomar und völlig unabhängig voneinander sind. Am Ende hat man aber ein "fertiges" Puzzle bzw. eine funktionale Software, welche das tut, was sie soll.
Durch Schnittstellen werden die Dinge miteinander verknüpft!
Das ist sogar ganz wichtig, bei diesem Konzept! Die Mittelmänner erwarten ausschließlich Schnittstellen als Konstruktor-Argument! Niemals eine konkrete Klasse! Dies wäre ein fataler Bruch bei der MPT und die Flexibilität wäre dahin.
Vielmehr sollte man den Vorteil darin sehen, dass eine Klasse beliebig viele Schnittstellen implementieren kann. (Zu diesem Thema wird es auch noch einen extra Beitrag geben, weil die Schnittstellen so wichtig sind.)
So kurze Datenwege, wie möglich!
Theoretisch dürften hier die transportierten Daten (siehe TFR und CPS) auf kürzestem Wege beim Ziel ankommen, weil das jeweilige Objekt direkt sagt, was es benötigt. (z.B. beim CPS)
Somit könnte das angeforderte "Ding" direkt übermittelt werden, ohne erst über zig Ecken wandern zu müssen. Wie gesagt, theoretisch! ;-)
So, das wären spontan die Vorteile. Das ganze hat leider auch einen offensichtlichen Nachteil:
SEHR AUFWÄNDIG!
Für jedes Triplet muss man zwei Schnittstellen anlegen und den Mittelmann vollständig implementieren.
Zudem werden da auch viele einzelne kleine Quellcodedateien anfallen.
Ja, das ödet wirklich sehr an und wäre zurecht ein Grund zu sagen: "OMG, da bleibe ich lieber bei quick & dirty!"
Da bleibt momentan nix anderes übrig, als in den sauren Apfel zu beißen oder es zu lassen.
(Ich habe da aber schon ein privates Projekt im Sinn, welches eine Art RAD-Tool werden soll, um mir diese Arbeit abzunehmen. Natürlich möchte ich dieses Tool konsequent mit der MPT ins Leben rufen. Das wäre dann auch gleich die beste Erprobung für die Praxistauglichkeit der MPT.)
Soviel dazu. Bis zum nächsten Artikel! :-)
Keine Kommentare:
Kommentar veröffentlichen