{"id":917,"date":"2016-02-23T17:15:04","date_gmt":"2016-02-23T15:15:04","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=917"},"modified":"2020-09-21T11:22:21","modified_gmt":"2020-09-21T09:22:21","slug":"maschinelle-erzeugnisse","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/maschinelle-erzeugnisse\/","title":{"rendered":"Maschinelle Erzeugnisse"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

In unserem Artikel Warum so gemustert?<\/a> haben wir erl\u00e4utert, welche Bedeutung Muster in der Softwareentwicklung haben. Weiterhin haben wir angek\u00fcndigt, weitere Entwurfsmuster vorzustellen, womit wir uns auch in diesem Artikel auseinander setzten werden.<\/p>\n

Wer von euch hat schon einmal ein gro\u00dfes Ganzes bestehend aus mehreren Einzelteilen per Software entwickelt, wie zum Beispiel ein Brettspiel, ein Auto, eine Spielwelt oder ein Haus? All diese Dinge haben gemeinsam, dass sie aus bestimmten Komponenten bestehen. So hat ein Auto \u00fcblicherweise eine Anzahl R\u00e4der, eine Karosserie, ein Motor – reicht schon fast, oder? \ud83d\ude09 Dabei spielt es keine Rolle, um welches Auto es sich tats\u00e4chlich handelt.<\/p>\n

Die naheliegende schnelle Implementierung erfolgt vermutlich sehr konkret. Wenn wir ein Schachspiel entwickeln wollen, w\u00fcrden wir ein passendes Spielbrett erstellen sowie die zugeh\u00f6rigen Spielfiguren. Was nun, wenn wir ein weiteres Brettspiel entwickeln wollen? Nat\u00fcrlich k\u00f6nnen wir dies einfach wieder konkret implementieren. Wer hier genauer hinschaut, entdeckt jedoch schon ein Muster. Ein Brettspiel besteht immer aus einem Spielbrett und Spielfiguren. Diese sind nat\u00fcrlich unterschiedlich in ihren Auspr\u00e4gungen, aber lassen sich entsprechend kategorisieren.<\/p>\n

Der konkrete Hausbau<\/h1>\n

Wechseln wir das Beispiel und bauen uns ein Haus \ud83d\ude42 Na gut, ein Fertighaus. Zur Vereinfachung unseres Vorhabens gen\u00fcgt uns ein Haus bestehend aus vier W\u00e4nden, einem Dach und einer T\u00fcre. Je nach Art des Hauses bestehen diese Komponenten aus \"\"<\/a>unterschiedlichen Materialien.<\/p>\n

Ein Baumhaus wird vermutlich selten aus Stein, sondern \u00fcberwiegend aus Holz gebaut und anstelle einer einbruchsicheren Stahlt\u00fcre verzichten wir f\u00fcr einen sch\u00f6nen Ausblick einfach auf die Eingangst\u00fcre.<\/p>\n

Erstellen wir dazu eine entsprechende Klasse f\u00fcr die Konstruktion der genannten Komponenten, k\u00f6nnte diese wie folgt aussehen:<\/p>\n

public class TreeHouseFactory {\n    Wall createWall() {\n        return new WoodenWall();\n    }\n\n    Roof createRoof() {\n        return new WoodenRoof();\n    }\n}<\/pre>\n
\"\"<\/a><\/p>\n
Hier haben wir eine kleine Fabrik f\u00fcr den Baumhausbau. Wir verwenden die beiden Komponenten Wall<\/em> und Roof<\/em>, welche hier aus Holz erstellt werden. Soweit so gut.<\/p>\n
Wie es so ist kommt nun die n\u00e4chste Anforderung und wir sollen neben unserem Baumhaus auch ein Country-Haus erzeugen. Dieses soll aus Holzw\u00e4nden, einem Holzdach sowie einer Holzt\u00fcre bestehen. Nichts leichter als das.<\/p>\n
public class CountryHouseFactory {\n    Door createDoor() {\n        return new WoodenDoor();\n    }\n\n    Wall createWall() {\n        return new WoodenWall();\n    }\n\n    Roof createRoof() {\n        return new WoodenRoof();\n    }\n}<\/pre>\n
Wer von euch besitzt nun scharfe Augen und erkennt im Vergleich mit dem Baumhaus ein Muster? Angenommen wir h\u00e4tten das Baumhaus auch mit einer T\u00fcre ausgestattet, h\u00e4tten wir die gleichen Komponenten(-arten) verwendet.<\/p>\n
Dies habt ihr wahrscheinlich schon aus der Aussage abgelesen, dass ein Haus grunds\u00e4tzlich aus bestimmten Komponenten besteht. Welche M\u00f6glichkeiten haben wir nun, dieses Muster nutzbar zu machen?<\/p>\n
Der abstrakte Hausbau<\/h1>\n
\"\"<\/a>Schauen wir uns das Entwurfsmuster Abstrakte Fabrik<\/strong> (Abstract Factory) im Zusammenhang mit unserem Bauvorhaben f\u00fcr die H\u00e4user an und wie es uns dabei helfen kann, den Code wiederverwendbar und sauber zu strukturieren.<\/p>\n
Also noch einmal ganz langsam. Wir ben\u00f6tigen f\u00fcr ein Haus immer W\u00e4nde, ein Dach und eine T\u00fcre – mit der Option, die T\u00fcre auch weg zu lassen. Dann machen wir daraus doch eine abstrakte Fabrik f\u00fcr H\u00e4user.<\/p>\n
public abstract class HouseFactory {\n    abstract Door createDoor();\n    abstract Wall createWall();\n    abstract Roof createRoof();\n}<\/pre>\n
Genau dies ist das Muster! Egal welches Haus wir bauen wollen, diese Komponenten sind immer mit dabei. Die beiden Fabriken f\u00fcr unser Baumhaus und das Country-Haus lassen sich dahingendend ganz leicht anpassen.<\/p>\n
public class TreeHouseFactory extends HouseFactory {\n    @Override\n    Door createDoor() {\n        return new NoDoor();\n    }\n\n    @Override\n    Wall createWall() {\n        return new WoodenWall();\n    }\n\n    @Override\n    Roof createRoof() {\n        return new WoodenRoof();\n    }\n}<\/pre>\n
public class CountryHouseFactory extends HouseFactory {\n    @Override\n    Door createDoor() {\n        return new WoodenDoor();\n    }\n\n    @Override\n    Wall createWall() {\n        return new WoodenWall();\n    }\n\n    @Override\n    Roof createRoof() {\n        return new WoodenRoof();\n    }\n}<\/pre>\n
Jede konkrete Fabrik legt damit fest, welche Komponentenarten jeweils dazu geh\u00f6ren. Die Zusammenstellung ist jedoch jedesmal identisch: W\u00e4nde, Dach und T\u00fcre.<\/p>\n
Wann ist dieses Entwurfsmuster sinnvoll anzuwenden?<\/h1>\n
Bei diesem Muster geht es darum, Produktfamilien zu erzeugen. Damit sind zusammengeh\u00f6rige Komponenten gemeint, welche in einer bestimmten Konstellation wiederholt auftreten. Zum Beispiel bei GUI-Bibliotheken k\u00f6nnen verschiedene Look & Feels \u00fcber dieses Muster abgebildet werden.<\/p>\n
Dabei herauszufinden, wann das Muster sinnvoll eingesetzt werden kann, spielt insbesondere das Open-Closed-Prinzip<\/a> eine wichtige Rolle. Wie wir in dem Prinzip gelernt haben, wollen wir unseren Code offen f\u00fcr Erweiterungen halten und gleichzeitig geschlossen gegen\u00fcber \u00c4nderungen. Immer dann, wenn wir das Schl\u00fcsselwort new<\/span> verwenden, erzeugen wir eine konkrete Abh\u00e4ngigkeit. Immer dann, wenn wir eine konkrete Abh\u00e4ngigkeit haben, verletzen wir das Open-Closed-Prinzip, da wir an dieser Stelle keine Erweiterungen vornehmen k\u00f6nnen, ohne den bestehenden Code zu ver\u00e4ndern.<\/p>\n
Wie aber erkennen wir das? Hierzu ist es notwendig, dass wir uns gedanklich von unserem Code trennen und uns auf die konzeptionelle Ebene unserer implementierten L\u00f6sung begeben. Hier m\u00fcssen wir nun Codeteile identifizieren, die sich \u00e4ndern k\u00f6nnen und von denen trennen, die gleich bleiben. F\u00fcr unser H\u00e4userbeispiel bedeutet das:<\/p>\n