Commit cbc34c5e authored by Jens Ehlers's avatar Jens Ehlers
Browse files

Fixes in docs

parent 60ed2aed
Pipeline #3811 passed with stage
in 34 seconds
<h4>Adapter</h4>
<p>Ein Adapter hilft zwei zunächst inkompatible Schnittstellen miteinander zu verbinden. Die Analogie dieses Entwurfsmusters zu einem Stromnetzadapter für Auslandsreisen ist naheliegend. Der Stromnetzadapter ermöglicht es, eine Steckdose mit einem Stecker für ein elektrisches Gerät zu verbinden, auch wenn der Stecker nicht direkt passt, weil er eine andere Schnittstelle aufweist.</p>
<img src="media/patterns_adapter_plug_socket.png" style="width:540px">
......
<h4>Kompositum</h4>
<p>Das Kompositum (engl. <i>Composite</i>) ist ein Strukturmuster, das angewendet wird, um Objekte, die sich ein gemeinsames Interface teilen, zu einer hierarchischer Baumstruktur zusammenfügen. Die grundlegende Idee des Kompositum-Musters ist es, sowohl primitive Objekte als auch zusammengesetzte Objekte, die aus mehreren primitiven Objekte bestehen, in einem Interface zu repräsentieren. Dadurch können einzelne Objekte und ihre Kompositionen einheitlich behandelt werden.</p>
<p>Es soll also folgende Frage durch das Muster beantwortet werden: Wie können in einer objektorientierten Sprache einzelne Objekte als Teile (= Komponenten) geschickt zu einem Ganzen (= Kompositum) zusammengesetzt werden?</p>
......
<h4>Fassade</h4>
<p>Wie der Adapter ist auch die Fassade (engl. <i>Facade</i>) einer Hüllenklasse. Während der Adapter hilft Methoden aus externen Komponenten aufzurufen und diese in das eigene System zu integrieren, ist es das Ziel der Fassade das eigene System nach außen so zu gestalten, dass es einfach durch externe Komponenten (= <i>Clients</i>) aufzurufen ist. Die Fassade gestaltet also die Schnittstelle über die Zugriffe von außen erfolgen. Es sollen i.d.R. nicht alle Methoden mit ihrer internen Signatur nach außen zur Verfügung gestellt werden. Die folgende Abbildung skizziert die Idee einer Fassade in einem UML-Komponentendiagramm.</p>
<img src="media/patterns_facade.png" style="width:500px">
......
<h4>Beobachter</h4>
<p>Das Beobachter-Muster (engl. <i>Observer</i> oder <i>Listener</i>) wird eingesetzt, wenn mehrere Objekte dauerhaft den Zustand eines anderen Objekts beobachten. Wenn sich der Zustand des beobachteten Objekts ändert, soll dieses alle seine Beobachter darüber informieren, damit diese sich ihrerseits reaktiv aktualisieren können. Das Muster entspricht also dem Prinzip: <i>"Don't call us, we'll call you!"</i></p>
<p>Wir können uns folgendes Beispiel vorstellen: Das beobachtete Objekt ist ein Feld zur Datumsauswahl. Dessen Beobachter sind eine Aufgaben- und eine Terminliste, die ihren jeweiligen Zustand (also die Aufgaben und Termine, die anzuzeigen sind) in Abhängigkeit des ausgewählten Datums ändern.</p>
......
<h4>Proxy</h4>
<p>Ein Proxy hat den Zweck, dass ein Client nicht direkt mit einem Zielobjekt kommunizieren kann. Stattdessen läuft die Kommunikation zwischen Client und Zielobjekt stets über den zwischengeschalteten Stellvertreter/Proxy. Dabei wird die ursprüngliche Anfrage des Client ggf. manipuliert, aufgezeichnet, verzögert, gänzlich blockiert oder ähnliches.</p>
<img src="media/patterns_proxy_illustration.png" style="width:600px">
......
<h4>Singleton</h4>
<p>Beginnen wir mit einem der einfachsten Erzeugungsmuster: dem Einzelstück (engl. <i>Singleton</i>). Das Singleton-Muster ist eng mit der Frage verknüpft, wie zur Laufzeit einer objektorientierten Anwendung sichergestellt werden kann, dass max. 1 Objekt einer Klasse erzeugt werden kann.</p>
<p>Singleton-Muster soll über folgendes Beispiel motiviert werden: Stellen wir uns vor, dass wir in einer Java-Anwendung eine Verbindung zu einer Datenbank aufbauen wollen. Dazu wird die folgende Klasse <code>DatabaseConnection</code> entworfen, die eine Methode zum Verbindungsaufbau und weitere Methoden zum Abfragen und Verändern der Daten enthält. Diese fachlichen Methoden werden in den Code-Listings weiter unten ausgeblendet.</p>
......
<h4>Strategie</h4>
<p>Das Entwurfsmuster Strategie (engl. <i>Strategy</i> oder <i>Policy</i>) beschäftigt sich damit, dass es auch in der Software-Entwicklung unterschiedliche Wege zum gleichen Ziel geben kann. Diese Wege entsprechen Algorithmen, die in Methoden implementiert werden und sich eine gemeinsame Schnittstelle teilen. Vereinfacht betrachtet betont das Strategie-Muster daher lediglich die konsequente Verwendung von Interfaces und die damit verbundene Polymorphie in einer objektorientierten Sprache.</p>
<p>Wenn es alternative Algorithmen als zielführende Wege gibt, soll dem Client zur Laufzeit ermöglicht werden, selbst zu entscheiden, welchen Algorithmus er als Lösungsstrategie verwenden möchte. Die Wahl der optimalen Strategie kann je nach Kontext unterschiedlich ausfallen. Es kann z.B. eine konkrete Strategie A geben, die besonders genaue Ergebnisse liefert, aber im Vergleich zu einer anderen Strategie B deutlich mehr Ressourcen (wie Prozessorzeit oder Speicher) erfordert, was dazu führt, dass ihre Berechnung länger dauert oder teurer wird. Strategie B dagegen benötigt weniger Ressourcen, liefert aber nur annähernd genaue Ergebnisse, die in Abhängigkeit des Kontexts ausreichend sein können oder eben nicht. Das Strategie-Muster erlaubt einen Wechsel der konkreten Strategie zur Laufzeit. Es wird in folgendem UML-Klassendiagramm visualisiert.</p>
......
......@@ -19,7 +19,7 @@
// document ready handler
$(function() {
if (document.location.hash == "") document.location.hash = "unit-uml";
if (document.location.hash == "") document.location.hash = "unit-goals";
displayUnit(document.location.hash);
$(".dropdown-item").on("click", function() { displayUnit('#'+$(this).attr("id")); });
......@@ -35,7 +35,7 @@
$(this).load('code/'+id+'.html');
});
// load units
// load module units
$('div[class="unit-part"]').each(function() {
var filename = $(this).attr('id');
$(this).load(filename + '.html', function() { // try this with $.get
......@@ -44,7 +44,7 @@
// add repo links
$(".repo-link").each(function() {
var href = 'https://git.mylab.th-luebeck.de/oncampus/patterns-and-frameworks' + $(this).attr('href');
var href = 'https://git.mylab.th-luebeck.de/oncampus/patterns-and-frameworks/blob/master' + $(this).attr('href');
$(this).attr('href', href);
});
});
......@@ -54,6 +54,7 @@
$("#content-" + id).prepend("<h3>"+title+"</h3>");
});
// search event handlers
$('#search input').on('focusout', function() {
search($(this).val().toLowerCase());
});
......@@ -65,14 +66,16 @@
// literature links
$(document).on('click tap', 'a', function() {
if ($(this).attr("href").startsWith("#cite-")) {
var href = $(this).attr("href");
if (typeof href !== "undefined" && href.startsWith("#cite-")) {
displayUnit('#unit-goals');
}
});
// finish preloading animation
$(window).on("load", function() {
$("body").addClass("loaded"); // finish preloading animation
});
$("body").addClass("loaded");
});
});
function displayUnit(id) {
......@@ -311,9 +314,9 @@
<div class="unit-part" id="architecture-mvc-mvvm-javafx"></div>
</div>
<div id="content-unit-microservices">
<!-- <div id="content-unit-microservices">
<div class="unit-part" id="architecture-microservices"></div>
</div>
</div> -->
<div id="content-unit-distributed-communication">
<div class="unit-part" id="distributed-communication"></div>
......
......@@ -138,7 +138,7 @@ Wenn eine Klasse abstrakte Methoden enthält, d.h. Methoden für die nur ihre Si
<p>Eine Unterklasse kann in der UML auch mehrere Oberklassen erweitern, was Mehrfachvererbung genannt wird. Mehrfachvererbung ist nur in wenigen Programmiersprachen zulässig (z.B. C++, Python) und in vielen anderen nicht (z.B. Java, C#). In der Programmierung werden Schnittstellen (<i>Interfaces</i>) gegenüber Mehrfachvererbung i.d.R. bevorzugt. Im folgenden Modell ist Mehrfachvererbung am Beispiel der Praktikanten-Klasse <code>Intern</code> illustriert. Probleme entstehen, wenn an die Unterklasse über verschiedene Vererbungspfade jeweils ein Attribut mit gleicher Bezeichnung vererbt wird oder wenn eine Unterklasse über mehrere Vererbungspfade von derselben Oberklasse erbt. Letzteres wird bildlich als <i>Deadly Diamond of Death</i> bezeichnet.</p>
<img src="media/uml_mehrfachvererbung.gif" style="width:380px">
<img src="media/uml_mehrfachvererbung1.png" style="width:380px">
<label>Mehrfachvererbung in der UML</label>
<p>Ein Interface spezifiziert i.d.R. nur Methoden-Signaturen, die dann eine gemeinsame Schnittstelle für alle Klassen bilden, die das Interface implementieren. Damit entspricht ein Interface einer abstrakten Klasse mit ausschließlich abstrakten Methoden. Seit Java 8 können in Interfaces aber auch Default-Implementierungen für Methoden angegeben werden. Da ein Interface keine Attribute und keine Assoziationen besitzt, ist es zustandslos. Das folgende Beispiel zeigt die beiden Klassen <code>Rectangle</code> und <code>Circle</code>, die jeweils das Interface <code>Shape</code> implementieren und damit dessen Methoden überschreiben müssen. Wenn die Methoden des Interface allgemein bekannt sind und eine Klasse ggf. sehr viele Interfaces implementiert, bietet sich die sogenannte <i><a href="https://martinfowler.com/bliki/BallAndSocket.html">Lollipop-Notation</a></i> als Kurzschreibweise an, um die Übersichtlichkeit in einem größeren Modell zu erhalten.</p>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment