Muster philipp

Wednesday 29th July 2020 02.43 Published by

Since we are looking for a design pattern, we first abstract the requirement. In a very abstract way, we want to consume external data and are looking for the best solution. As you see, we’ve solved the original request, but we’ve also created a template for a whole range of problems. We can use this pattern for any kind of parallel data processing. And from this pattern, we can quickly derive variants, for example for sequential instead of parallel data processing. Let’s look at Design Patterns with explain design patterns is pretty straightforward: The idea is, that you do not look for specific solutions to individual problems, but abstract problems on a generic requirement pattern and then look for solutions to those parent patterns. In order to find a design pattern, we want to abstract the solution and for this we first have to make a fundamental distinction: should the files be processed individually or together? Such a generic solution — a design pattern — can then be used for all similar problems to quickly find the best implementation. These considerations result in a first, very simple design pattern that can be used for many tasks. Dazu begreifen wir Beilagen als “Wrapper”, als Hülle, die wir um ein Basisgericht legen.

Es sind Objekte, die ein Gericht (beispielweise eine Basisgericht) besitzen. also eine Instanzvariabale auf ein solches besitzen. Soll eine Salatbeilage seinen Preis ausgeben, so fragt er zuerst sein Hüftsteak nach dessen Preis und addiert anschließend seinen eigenen Salatpreis hinzu. Me, giving my presentation. Don’t worry, the bottle of wine is not my snack for the talk. Soweit so gut. Doch wie so oft in der Softwareentwicklung ändern sich die Anforderungen an unsere Modellierung: Das Restaurant möchte nun alle (!) Basisgerichte (Tofu, Garnelen, Hüftsteak, Wiener Schnitzel) mit allen möglichen Beilagen (Nudeln, Pommes, Bratkartoffeln, Salat, Suppe) modellieren. Bei unserer jetzigen Modellierung würde dies zu einer Klassenexplosion führen.

4 Basisgerichte * 5 Beilagen = 20 Klassen/Gerichte. Die konkreten Basisstreams (Concrete Components) können durch andere Streams beliebig dekoriert werden, um ihnen damit zusätzliche Funktionalität zuzufügen. So fügt ein BufferedInputStream dem Basisstream einen Buffer hinzu und ermöglicht damit performantes Lesen. Dieser kann wiederum weiteren Decoratorstreams übergeben werden bis das gewünschte Verhalten erreicht wurde. Das Decorator Design Pattern ermöglicht das dynamische Hinzufügen von Fähigkeiten zu einer Klasse. Dazu wird die Klasse, dessen Verhalten wir erweitern möchten (Component, Komponente), mit anderen Klassen (Decorator, Dekorierer) dekoriert (vgl. engl. “to wrap”: umhüllen). Das heißt der Decorator umschließt (enthält) die Component. Der Decorator ist vom selben Typ wie das zudekorierende Objekt, hat somit die gleiche Schnittstelle und kann an der selben Stelle wie die Component benutzt werden.

Er delegiert Methodenaufrufe an seine Component weiter und führt sein eigenes Verhalten davor oder danach aus. No, do not worry. Of course, I have also prepared an example that makes this abstract explanation a little more tangible.

Categorised in: Uncategorized

|