Welche Design Patterns sind in Architektur muster pipes und filter enthalten?
Irgendwie wenn ich nachdenke wie die Struktur aufgebaut ist, denke ich an das State pattern also das Zustand pattern?
bitte nur antworten wenn ihr euch wirklich sicher seid?
Ich versteh die Frage nicht ganz, "PipesAndFiltersArchitecture" sind Design Pattern.
Beispiele: Compiler, Datenkompression, Kodierungen MPEG, MP3, usw. 12
Doch, wenn man Design Pattern als die typischen Gang of Four-Pattern versteht, und Pipes and Filters als Architektur-Pattern, kann man erstere in (oder „für“) letzterem finden
@FantastischMan, welche Design-Pattern sind die denn so bekannt?
Doch, wenn man Design Pattern als die typischen Gang of Four-Pattern versteht, und Pipes and Filters als Architektur-Pattern, kann man erstere in (oder „für“) letzterem finden
@FantastischMan, welche Design-Pattern sind die denn so bekannt?
fate pattern, state pattern composite pattern. Ich glaube dass das eine kombination aus state und composite ist aber unsicher. ich kenne eig alle grundlegende.
Verhaltensmuster, Strukturmuster und Erzeugungsmuster
Also man kann durchaus ein Architekturmuster wählen, aber wenn es um die genaue Modellierung geht, dann sehe ich keinen Grund, wieso es da eine Einschränkung geben sollte. Das sind doch zwei Paar Schuhe die unterschiedliche Bereiche ausdrücken. Was ich wie bauen kann für einen Filter ist da doch egal. Da kann doch prinzipiell jedes Entwurfsmuster zum Einsatz kommen. Ich kann Builder benötigen, ich kann mit dem Strategy Muster Verhalten Kapseln u.s.w.
Das ist doch wie beim Thema: Ich will hein Haus bauen - welche Materialien kann ich verwenden. Da kannst du alles verwenden - selbst Dinge die für tragende Wände nicht taugen kannst du noch für die Inneneinrichtung verwenden...
Oder sehe ich das jetzt erst einmal zu einfach und da gibt es dann doch Ausschluss-Gründe? Aber wie beim Innenausbau: wer weiß, was ich bei den Filtern oder bei der Pipe im Detail noch so brauche.
Daher muss ich gestehen: ich sehe in der Frage auch nicht wirklich einen Sinn.
ne es gibt Patterns sie zusammen arbeiten und eine Architektur bilden darum geht es.
Es geht darum welche wichtige patterns interagieren um ein ähnliches Verhalten wie pipes und Filters zu bekommen.
Also man kann durchaus ein Architekturmuster wählen, aber wenn es um die genaue Modellierung geht, dann sehe ich keinen Grund, wieso es da eine Einschränkung geben sollte. Das sind doch zwei Paar Schuhe die unterschiedliche Bereiche ausdrücken. Was ich wie bauen kann für einen Filter ist da doch egal. Da kann doch prinzipiell jedes Entwurfsmuster zum Einsatz kommen. Ich kann Builder benötigen, ich kann mit dem Strategy Muster Verhalten Kapseln u.s.w.
Für die meisten Architektur-Muster gibt es aber durchaus eine naheliegende Wahl an Design-Pattern, die man für die Umsetzung nutzt - wobei Naheliegend von "sinnvoll" bis "notwendig" reicht.
Das ist doch wie beim Thema: Ich will hein Haus bauen - welche Materialien kann ich verwenden. Da kannst du alles verwenden - selbst Dinge die für tragende Wände nicht taugen kannst du noch für die Inneneinrichtung verwenden...
Üblicherweise kommen bei Wohnhäusern aber Pattern wie Räume, Fenster, Türen zum Einsatz - wie man allerdings große Hallen oder vollkommen autarke Systeme baut, ist da eher Nebenschlich
Für MVC hat er ja selbst schon Design-Pattern genannt - Oberserverpatten und Strategiepattern werden üblicherweise als notwendig angehen, Observer, da View das Model beobachtet, Strategie, weil (zumindest im reinen MVC) die Controller eine Strategie für die View sind. Composite ist in den üblichen Umsetzungen auch verwendet.
fate pattern, state pattern composite pattern. Ich glaube dass das eine kombination aus state und composite ist aber unsicher. ich kenne eig alle grundlegende.
Verhaltensmuster, Strukturmuster und Erzeugungsmuster
Beschreib doch mal, wie du State und Composite in Pipes & Filters verwendet siehst.
Und umgekehrt: welche Rollen siehst du in Pipes & Filters und welche Anforderungen siehst du an dieser gestellt. (Rollen meint dabei keinen Rollen aus irgendwelchen Pattern, sondern einfach nur "es gibt XY, und XY macht das")
Im Grunde genommen kann man die ganzen pipes als zustande sehen und durch diese Filters kann man dann die zustande andern
> pipes = zustande
Und Composite auch da diese pipes teilweise eine Hierarchie haben.
Die Wurzel wäre dann im Grunde genommen der erste Pipe und der letzte pipe wäre demnach das Blat
Was für Elemente es dabei so gibt. Wie oben schon gesagt, was gibt es, und was für Anforderungen gibt es.
Im MVC gibts zum ganz offensichtlich ein Model, welches die Domäne der Anwendung darstellt, das sollte UI-unabhängig sein. Daneben dann Pärchen aus View und Controller, wobei erstere die Implementierung des Controllers nicht kennen soll und die View muss irgendwie die Änderungen des Models mitbekommen.
Ich würde ja mal ein konkretes Beispiel ins Spiel bringen:
In einem Naturpark gibt es eine Anzahl von Aufnahmestationen. Kommen die Tiere in deren Nähe, wird gespeichert, welches Tier, wann wo war. Aus technischen Gründen werden diese Daten auf SD-Karten gespeichert. Zur Verarbeitung werden die gespeicherten Daten aller SD-Karten zu einer großen Liste zusammengefügt.
Im Sinne der Stream-Verarbeitung von Linux könnte man nun Filter schreiben, die aus dieser Rohdatei die gewünschten Informationen herausfinden und in eine neue Datei speichern.
Bloß im Sinne des OOAD würde ich etwa so modellieren:
- Eine Aufnahme enthält Tiernummer und Uhrzeit
- Eine Station hat viele Aufnahmen.
- Der Park hat viele Stationen.
- Im Park leben viele Tiernummern
Ich finde, dass diese Modellierung nicht so wirklich passt zu "Pipes and Filters".
hat jemand mal ein besseres Beispiel? Oder sehe ich da was falsch?
Generell passt natürlich nicht jedes Pattern zu jedem Problem, und die meisten Probleme kann man auf verschiedene Arten modellieren, und die meisten Domänen muss man auch für verschiedenen Dinge verschieden modellieren.
Das ist auch eine passende Modellierung - nur eine andere Ebene/Sicht, als man bei Pipes und Filters hat.
Widerspricht sich auch keineswegs, du kannst das ganze durchaus so modelliert haben, und trotzdem Pipes und Filters nutzen.
zB wenn du eine Suche umsetzen willst, ein Filter filtert nach Uhrzeit, einer nach Station, einer nach XY. Das ganze lässt sich dann beliebig kombinieren, der erste Filter bekommt einfach alle Daten, der erste Filter filtert dann eine Teilmenge, der zweite bekommt die Teilmenge und filtert noch kleiner, usw.
Eine Softwarearchitektur beschreibt die Struktur eines Systems, wobei für ein System mehrere Architekturen angegeben werden können, je nachdem welchen Abstraktionsgrad man ansetzt und welche Sichtweise man einnimmt.
So ist
Bash:
ls -lS |tail -1 |cut -f 1 -d " "
ein System, das drei Prozesse in "Pipe und Filter"-Architektur miteinander verbindet, um mir die Zugriffsrechte der kleinsten Datei im Verzeichnis anzuzeigen. Welche Entwurfsmuster innerhalb von "ls", "tail" und "cut" angewendet wurden, spielt hier keine Rolle.
Was aber, wenn man Pipes und Filter selbst umsetzen will? Die Pipe dient als Puffer zur Entkopplung von Datenlieferanten und -konsumenten. Ein sehr unmittelbarer Ansatz wäre es, den Produzenten und den Konsumenten in separaten Threads laufen zu lassen, die sich die Pipe teilen. Die Pipe könnte als Blocking Queue realisiert werden. Andererseits ließe sich aber auch das Chain-Of-Responsibility-Patterns anwenden, das innerhalb der klassischen Entwurfsmuster in Bezug auf das Verhalten dem "Pipe und Filter" wohl am nächsten kommt.
ich denke, dass mihe7 einen wichtigen Punkt angesprochen hat. Wenn ich eine Filter-and-Pipe Arcitektur anwenden will, dann habe ich doch als wichtigstes die Pipes als FIFO-Speicher. Und die Filter selbst lesen das Ende der einen Pipe und schreiben in den Anfang der anderen Pipe. So gedacht, würde sich MrBrown's Idee am ehesten denken lassen, dass jeder Filter die vorhandene Datenmenge reduziert. Dabei werden jedoch keine Operationen auf die Daten wie sortieren angewendet, wohl aber neben dem Filtern das Ersetzen und Einfügen von Informationen, wobei aber die Datenreihenfolge erhalten bleibt.
Die müssen allerdings nichts speichern (oder puffern), die können das einfach direkt an den nächsten Filter weitergeben. Theoretisch wäre auch ein nextFilter.write(...) in einem Filter eine Pipe.
So gedacht, würde sich MrBrown's Idee am ehesten denken lassen, dass jeder Filter die vorhandene Datenmenge reduziert. Dabei werden jedoch keine Operationen auf die Daten wie sortieren angewendet, wohl aber neben dem Filtern das Ersetzen und Einfügen von Informationen, wobei aber die Datenreihenfolge erhalten bleibt.