Diskussion:Muster

Name

Ich würde vorschlagen, dass Buch nach Entwurfsmuster zu verschieben. Unter dem Titel ist das Buch IMHO besser aufgehoben. -- Daniel B 20:49, 15. Mär 2005 (UTC)

Ack. Finde auch dass das ein verständlicher Titel wäre. --Moolsan 22:53, 15. Mär 2005 (UTC)

Möglicherweise sogar Software-Entwurfsmuster ? --Moolsan 23:17, 15. Mär 2005 (UTC)33

Ist dies notwendig? Entwurfsmuster schränkt das Buch ein (sinnvoll?). Software noch davor (?) - es steht unter Programmieren. Grds. wäre ich mit Entwurfsmuster eher einverstanden. Insbesondere halte ich Software davor zu setzen für ungünstig in Hinblick auf den alphabetischen Index. (Wir können ja alles umbenennen in Softwareentwicklung mit <Programmiersprache> *g* ;-) --Bastie 08:04, 16. Mär 2005 (UTC)

Habe gerade nochmal meine Literatur durchgestöbert "Analysemuster" --Bastie 11:14, 16. Mär 2005 (UTC)

Also Entwurfsmuster scheint aber schon ein Recht verbreiteter Begriff zu sein. siehe [1]. Der englische Begriff dafür ist meines Wissens auch Design Patterns. Aber im Grunde ist's mir egal ;)

--Moolsan 11:21, 16. Mär 2005 (UTC)

Das Buch von Gamma & Co heißt auch Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software. Deshalb bin ich schon der Meinung, dass der Titel so passt. -- Daniel B 21:17, 17. Mär 2005 (UTC)

"Analysemuster -wiederverwendbare Objektmodelle" von Martin Fowler (Addison-Wesley). M.E. ein Buch was man nach dem der GoF lesen sollte. Wesentlich praxisnaher als "Entwurfsmuster..." aber nur als Aufbau zu diesem geeignet. Mein (hoffentlich) schlagendes Gegenargument ist: Wir wollen doch wohl kaum eine neue Übersetzung zum Buch der GoF bieten sond besser ;-) sein *g*.--Bastie 06:39, 19. Mär 2005 (UTC)

Ich bin auch für den Namen "Entwurfsmuster" - weil Design Patterns u. a. dafür da sind, ein einheitliches Vokabular zur Verfügung zu stellen. Und die verbreiteste Bezeichnung dafür ist - soweit ich weiss- Entwurfsmuster. Davon abgesehen ist das Wort "Muster" alleine nicht aussagekräftig.--Aler 16:34, 28. Mär 2005 (UTC)

Auch ich bin für das Umbenennen nach "Entwurfsmuster". Muster ist nicht aussagekräftig, und Entwurfsmuster scheint recht deutlich geprägt zu sein mittlerweile. --Schmiddtchen 15:36, 30. Jan. 2007 (CET)

Bin auch für "Entwurfsmuster" - falls überhaupt noch jemanden dieses Thema interessiert... ;-) --Gruß, pcworld 15:52, 10. Mai 2009 (CEST)

Name und Inhalt: Derzeit sind "nur" Entwurfsmuster in diesem Buch enthalten. Ich würde gerne auch ein bisschen über Architekturmuster schreiben. Ich werde vl. mal einfach damit beginnen, dann sehen wir, wie es sich entwickelt. Ev. kann man dann den Namen anpassen --Steelli 19:29, 21. Sep. 2015 (CEST)

Aufbau

Ich habe gerade zwei der Muster (Singleton, Schablonenmethode) mit Bildern ausgestattet und auch ein bisschen Inhaltlich ergaenzt. Da ich die arbeit des Orginalautors nicht allzusehr umwerfen wollte, habe ich mich an seine Struktur gehalten. Ich empfinde diese jedoch als hinderlich und schlage vor:

• Code in den Muster-Erklaerungen (meinetwegen auch OO-Pseudocode, wenn die Sprachunabhaengigkeit gewahrt bleiben soll): Um Beispiele vorzuexerzieren waere das doch sehr hilfreich
• Wo wir gerade dabei sind: Ausfuehrliche Beispiele! Denn nur so kann sich auch der Novize was drunter vorstellen
• Vielleicht andere struktur:
  • Kurze Ein-Satz-Definition wie bisher
  • Laengere Einfuehrung und motivierendes Beispiel
  • UML
  • Implementation und Verwendung (letzteres bezieht sich darauf wie die "Umwelt" dieses Muster verwendet)
  • Loesung zum Motivierenden Beispiel
  • Meinetwegen Links zu verschiedenen Sprachen
  • Verwandte Muster

wobei diese Struktur natuerlich flexibel zu handhaben waere --Marwes 00:20, 12. Jan 2006 (UTC)

Über die Struktur können wir genr diskutieren. Ein paar allgemeine Anmerkungen.

• Ich hatte als Ziel ein Sprachunabhängiges Buch hier abzustellen. Der Grund ist einfach: Beispiele die in einer Programmiersprache :geschrieben werden sind immer ein "Quasi"-Ausschluß für jemanden der diese nicht kann.
• Zu den Beispielen - wenn du Beispiele hast rein damit. Mir fällt es etwas schwer ausführliche Beispiele (sprachneutral) zu :formulieren die ein Einsteiger noch versteht. Zu konkrete Beispiele haben IMHO auch immer etwas absolutes ansich...
• "Verwendung (letzteres bezieht sich darauf wie die "Umwelt" dieses Muster verwendet)" - ich verstehe nicht was du meinst!

Generell ist mir die Struktur egal - ich möchte lediglich eine Einheitlichkeit haben. Vielleicht legst du unter Aufbau mal ein Beispiel zum Vergleich ab Muster:_Vorlage_neu. Daran ließe sich besser diskutieren.

Ansonsten bin ich mit der Entwicklung -hier- im moment eher unzufrieden, da irgendwas reinkopiert oder -geschrieben wird ohne dass die jeweiligen Artikel weiter ausgebaut werden (z.B. Fasade) - was ausdrücklich nicht gegen die jeweiligen Autoren gerichtet werden soll. Allerdings hinterläßt dieses bei mir einen faden Beigeschmack (sorry -persönliche Meinung)

--Bastie 13:44, 14. Jan 2006 (UTC)

Zur Sprachproblematik: Die am weitesten verbreiteten Sprachen sind doch sicherlich: C++, C# und Java. Wenn wir uns einer Java-ähnlichen Syntax bedienen und in der Einleitung darauf hinweisen, sollte es doch eigentlich keine Verständnisprobleme geben, oder? Und es wäre wirklich hilfreich im Text einige Code-Schnipsel unterbringen zu können: Beim Muster Schablonenmethode habe ich das z.B. gemacht - allerdings noch mit sehr stark abstrahiertem Code...

"Zu konkrete Beispiele haben IMHO auch immer etwas absolutes ansich..." den Satz versehe ich nicht - ist das nun eine zustimmende oder ablehnende Äußerung?

Mit "Verwendung" meine ich, wie ein Klient von diesem Muster Gebrauch macht (z.B. bei Singleton: Aufruf der gibInstanz()-Methode).

Ich habe mir zunächst mal folgendes vorgenommen (gemäß dem Motto mit dem Einfachen zu beginnen): Für alle Muster UML-Grafiken erstellen (evtl. für ein paar auch Sequenz-Diagramme - ist z.B. für den Beobachter recht hilfreich) und Beispiele coden. Bisher habe ich Grafiken für: Fassade, Singleton, Schablonenmethode, Beobachter, Kompositum, Adapter und Iterator. Code existiert für: Singleton, NullPattern, Beobachter (neu), und Iterator (neu).

Ein paar Worte zu den Bildern: Zwar gibt es in der Wikipedia schon teilweise welche, ein einheitlicher Look wäre allerdings wünschenswert, weshalb ich lieber neue malen will.

Zum Code: Ich bin dafür möglichst keine Bibliotheken zu verwenden, sondern ausführbaren (mit main() :-) ) Code "from scratch" zu schreiben. Grund: In den Bibliotheken kommen die meisten Muster in leicht "verwaschener" Form vor; für den "ersten Kontakt" scheint es mir aber besser zu sein, wenn sie in "Reinform" und in möglichst großer Übereinstimmung mit dem beschreibenden Text vorliegen. Ich habe versucht dies bei Iterator und Beobachter umzusetzten.

Wir sollten ausserdem eine Richtlinie zum Umgang mit englischen Ausdrücken einhalten (z.B. alles deutsch und englisch in Klammern, oder ...) - wie handhaben das andere Bücher? (werde mal nachschauen). Grüße, Markus

Nachtrag: das mit den Umlauten tut mir leid - im Moment sitze ich an meinem Notebook, aber die anderen Änderungen habe ich von einem Uni-Rechner aus gemacht (mache gerade ein Auslandssemeter)

Mehr allgemeine Erklärungen

Hi und erstmal Dnake das einer etwas Umfassendes zu diesem Thema schreibt, bin Fachinformatiker Anwendungsentwicklung und steige da nicht wirklich durch, weder in der Berufschule noch im Betrieb ist da was zu hören. Deswegen wäre es schön, wenn etwas mehr auf den allgemeinen Kram eingegangen werden könnte (aber bitte etwas verstäändlicher als im Wikipedia Artikel zu dem Thema ;)) Was mich z.B. interessieren würde -Wozu? Klassen unterscheiden sich doch je nach Anwendungsfall -Wie anwenden? Gibt es eine Sprache für Paterns, wie erzeuge ich daraus Klassen/Code ...und sicherlich einiges mehr ^^

Zuerst: lies das Buch der Viererbande (Design Patterns: Elements of Reusable Object-Oriented Software ) - ich schätze das hier wird noch eine weile eine Baustelle bleiben :-)

In aller Kürze zu deinen Fragen: Ganz unabhängig für welchen Einsatzzweck eine Software geschrieben wird, treten immer wieder ähnliche (Entwurfs/Architektur-)Probleme auf: z.B. kann sich bei der Simulation einer Schaltung der Wert an einem Port ändern und mit diesem Port verbundene Bausteine müssen darüber informiert werden; oder bei einer Krankenhausverwaltungssoftware wird ein neuer Patient aufgenommen und dieser sollte doch dann bitte sofort in verschiedenen anderen Modulen auftauchen - was haben diese beiden Probleme nun gemeinsam? In beiden Fällen soll eine Änderung an einem Objekt (Binärport bzw. Patientenverwaltung) einer Reihe von anderen Objekten (an den Port angeschlossenen Bausteinen bzw. Labormodul, Stationsmodul, Küchenmodul,...) bekanntgemacht werden. Ein Entwurfsmuster ist nun eine Art Lösungsschablone für bestimmte Problemklassen (schaue dir für die Lösung der Beispielprobleme mal den Beobachter an). Und natürlich ist diese Schablone für ein konkretes Problem anzupassen!

Zweck der Übung: das Rad nicht zweimal erfinden (und insbesondere kein eckiges Rad erfinden); bessere Kommunikation unter den Entwicklern; hilft Code besser zu verstehen; und weitere (-> Buch von Gamma et altera)

Vielleicht hast du es ja schon gelesen: Entwurfsmuster stammen ursprünglich aus der Architektur - und ich finde da lassen sich schöne Analogien finden; z.B. diese: Das Problem besteht darin, dass Personen vom Erdgeschoss ins weit entfernte Dachgeschoss kommen müssen (ich schätze dieses Problem tritt in der Architektur recht häufig auf) - die Schablone zur Lösung: ein vertikaler Leutetransporter! (manche Zeitgenossen nennen sowas auch "Aufzug"). Nun gibt es aber durchaus verschiedene Arten von Aufzügen - das allgemeine Konzept eines vertikalen Leutetransporters muss eben für die verschiedenen konkreten Probleme angepasst werden: Expressaufzug, wenn's schnell gehen soll; ein Lastenaufzug, wenn's schwer wird; ein gläserner Aufzug, wenn's ums Repräsentieren geht; ...

Schließlich zum Code: Schau dir einfach die Beispiele an, dann siehst du, wie's geht.

Und hier noch eine Aufgabe für dich: Schreibe ein Beispiel für das Kompositum: Es geht darum, Zeichenobjekte hierarchisch zu gliedern; Primitivtypen (Kreis, Rechteck,...) können zu Gruppen zusammengefasst werden, Gruppen wiederum können mit anderen Graphikobjekten (Primitive oder Gruppen) zu noch größeren Gruppen zusammengefasst werden, und diese wiederum... Außerdem sollen Grafikobjekte "gezeichnet" werden können (sprich: Bezeichnung auf die Konsole schreiben) - eine Gruppe zu zeichnen heißt dabei nichts anderes als ihre Bestandteile zu zeichnen (welche ja wiederum Gruppen sein können...). Ich freue mich auf deine Lösung!

Viele Grüße -- Marwes 04:24, 28. Jan 2006 (UTC) (zur Uhrzeit: du musst 8 Stunden abziehen :-)

Ich habe mal aus deinen Ausführungen Marwes, den Fragen ein Kapitel Einführung begonnen.--Bastie 11:33, 28. Jan 2006 (UTC)

Da ja das GoF-Buch doch recht teuer ist, hier ein Tipp: Im vermutlich ersten Wiki der Welt [2] werden seit ewigen Zeiten Muster (engl. Patterns) diskutiert - die haben da scheinbar echt Ahnung vom Thema. Der Link sollte vielleicht sogar ins Buch, falls mal jemand mehr wissen möchte. -- Schmidt2 16:18, 12. Apr. 2008 (CEST)

Sinn dieses Projekts

Das Buch

Gamma, Erich ; Helm, Richard ; Johnson, Ralph E. ; Vlissides, John: Entwurfsmuster. Elemente wieder verwendbarer objektorientierter Software. Bonn u.a.: Addison-Wesley, 1996

• hat den gleichen Namen wie dieses Wikibook
• enthält größtenteils die gleichen Muster
• enthält sehr ähnliche Beschreibungen
• enthält fast identische UML-Diagramme
• hat einen besseren Aufbau der Muster (IMHO)

Warum soll eine Kopie dieses Buches angefertigt werden? Neben Copyright-Problemen sehe hier ich den Sinn nicht.

Einige Argumente finden sich unter Hilfe:Warum inhaltsoffene Lehrbücher?. --Yuuki Mayuki 05:51, 27. Mär 2006 (UTC)

"Entwurfsmuster" enthält ausdrücklich nur einige wichtige Muster - nicht alle. "Entwurfsmuster" enthält keine konkreten Beispiele einer in einer / mehreren Programmiersprachen (siehe Links zu Java Standard) Nebenbei "ähnliche" Beschreibung, gleiche Muster, fast identische UML Diagramme ist eine logische Folge des Sinn und Zwecks von (Entwurfs)mustern. Dieses Buch heißt eigentlich "Muster" (auch zur Abgrenzung). Bastie

Aus dem Artikelquelltext hierher verschoben

Kann sich bitte jemand der Eindeutschung der Gruppenzusammenfassungen und der Begriffe einiger Muster annehmen?

Ich sehe ja ein, dass sie "eingedeutscht" werden sollen, aber ich kenne keine deutschen Begriffe, die gleichzeitig den geläufigen Namen des Musters widerspiegeln, da sie i.d.R. nur im Kontext des Englischen benutzt werden und "krampfhafte Zwangseindeutschung" m.E. das Ziel verfehlen würde.

Danke.

Mindestens die englischen Originalnamen sollten mit erwähnt werden!! --Schmiddtchen 15:33, 30. Jan. 2007 (CET)

Schreibweisen

Im Kapitel PipesAndFiltersArchitecture habe ich ein paar Korrekturen vorgenommen:

• In ein Kapitel gehören keine Überschriften der 1. Ebene, auch die Wiederholung des Kapitelnamens ist zu vermeiden. Mehr dazu auf dieser und anderen Hilfe-Seiten.
• Bei zusammengesetzten Begriffen dürfen vor und nach dem Bindestrich keine Leerzeichen stehen (Rechtschreibregeln).
• Auch aus diesem Grund empfehle ich, über die Schreibweisen genauer nachzudenken:
  • Die Mischung von deutschen und englischen Fachbegriffen wie bei Pipes-And-Filters-Architektur ist zumindest fragwürdig. (Müsste "and" im Englischen nicht kleingeschrieben werden?)
  • Die Zusammensetzung von vier Wörtern zu einem Konstrukt liest sich nicht schön (das gilt allerdings auch für alle Varianten, über die ich nachgedacht habe; also sollte man das übernehmen, was sich in der Fachwelt eingebürgert hat, aber das in der Projektdefinition ausdrücklich erwähnen).
  • In diesem Zusammenhang würde ich die englische Bezeichnung hinnehmen, auch wenn ich vehement gegen Denglisch bin. Ich empfehle aber, englische Begriffe abzusetzen, z.B. durch Kursivschrift.
• Bitte beachte im fortlaufenden Text auch den Unterschied zwischen dem (kurzen) Bindestrich und dem (langen) Gedankenstrich – letzterer findet sich oben in der Liste der Sonderzeichen direkt hinter den Gänsefüßchen – und die richtige Schreibweise von Abkürzungen (nicht zB, sondern z. B. usw.).
• Die Navigation sollte von vornherein mit <noinclude> umschlossen werden, damit sie in der Druck- oder PDF-Version ausgeblendet wird. (Es ist einfacher, das gleich zu machen als am Schluss überall nachträglich).

Danke schön! -- Jürgen 14:49, 22. Sep. 2015 (CEST)

Danke für die vielen nützlichen Tipps und Hinweise! Hab sie jetzt auf "Pipes und Filter" geändert. Aber die Begriffe "Pipe" und "Filter" sind mMn hierzulande Standards im Informatik-Bereich. Diverse "künstlich eingedeutschten" Begriffe, mit denen der/die LeserIn letztendlich vermutlich weniger anfangen kann als mit den englischen Originalen wollte ich vermeiden. Aber wer will kann die Überschrift natürlich auch gerne komplett umschreiben, das wäre auch Problem für mich ;-) -- Steelli 15:37, 22. Sep. 2015 (CEST)

Bin auch der Meinung, dass man die Fachbegriffe "Pipe" und "Filter" beibehalten sollte. -- Stephan Kulla 17:12, 22. Sep. 2015 (CEST)

Das hatte ich oben ebenfalls geschrieben: "die englische Bezeichnung hinnehmen" Nicht hinnehmen wollte ich die Kombination mit "and" und "Architektur". – Problematisch sind die künstlichen Kapitelnamen, die weder nach deutschen noch nach englischen Regeln gebildet wurden. Ich befürchte, das muss so bleiben (schon wegen der Vielzahl betroffener Kapitel). Ersatzweise ist es möglicherweise nötig, von der Empfehlung "keine Wiederholung des Kapitelnamens" abzuweichen, dann aber bitte mit Vorlage:Überschriftensimulation 1 und nicht mit einem Gleichheitszeichen (als Begründung dient das automatisch erzeugte Inhaltsverzeichnis). -- Jürgen 17:37, 22. Sep. 2015 (CEST)

Status / Vollständigkeit

Ich habe die Vorlagenseite (Muster:_Vorlage) an die vom ursprünglichen Autor als (fast) vollständige Kapitel gekennzeichneten Inhalten/Überschriften angepasst. Ich werde versuchen, sukzessive an den Entwurfsmustern zu arbeiten, und die Befüllung aller Überschriften der Vorlage anzugehen. Wenn dies erreicht ist, stelle ich ein Kapitel auf "fertig" (also Status 10). Alle die wollen können/dürfen/sollen aber immer von der Möglichkeit gebrauch machen, ein bereits als "fertig" markiertes Kapitel nach Belieben zu erweitern. Zu jedem dieser Themen könnte man dutzende Seiten schreiben :) --Steelli 15:15, 28. Sep. 2015 (CEST)

@Steelli: Super, danke dir   -- Stephan Kulla 20:40, 28. Sep. 2015 (CEST)