Diskussion:Entwurfsmuster

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Entwurfsmuster“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Im Archiv sind viele Abschnitte nicht erledigt

--Rainald62 (Diskussion) 16:38, 19. Jul. 2014 (CEST)

Schiebe die Abschnitte, die deiner Meinung nach nicht erledigt wurden bitte wieder hierher. Der Bot macht das Verschieben automatisch. Ich hab jetzt die Verschiebung auf 30 Tage ausgedehnt (d.h. 30 Tage nachdem jemand einen Abschnitt als erledigt gekennzeichnet hat, wird er verschoben). (nicht signierter Beitrag von N.N. (Diskussion | Beiträge) tt.mm.yyyy)

Es gibt dazu auch Vorlage:Nicht archivieren --Geri, ✉  23:40, 29. Nov. 2020 (CET)

Lückenhaft

Ungefähr 838.000 Google-Treffer für producer-consumer pattern, welches ich weder hier noch in der engl. Version finde (ist vielleicht die Hitze). --Rainald62 (Diskussion) 16:38, 19. Jul. 2014 (CEST)

@Rainald62: WP:Sei mutig. --Geri, ✉  04:51, 2. Dez. 2020 (CET)

Enterprise Integration Patterns

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. Die geplanten Erweiterung werden in Summe länger als der Archivierungs-Threshold dauern und damit das alles nachvollziehbar bleibt...

Die folgenden Pattern sollten noch ergänzt werden - https://www.enterpriseintegrationpatterns.com/patterns/messaging/ Wenn ich mal Zeit habe mach ichs... --Sebastian.Dietrich ✉ 12:44, 16. Nov. 2020 (CET)

Hallo Sebastian, wir können das, wie erwähnt ;), auch in Kooperation machen. Thematisch interessiert es mich jedenfalls sehr. Zeit ist bei mir derzeit etwas knapp, aber z.B. Korrekturlesen wird sich schon ausgehen. (Meine Frau nennt mich eh immer einen ewigen Besserwisser/Oberlehrer. :) --Geri, ✉  17:08, 27. Nov. 2020 (CET)

Ich hatte ohnedies nur vor, die Patterns in die Tabelle einzuordnen (und keine extra Seite je Pattern anzulegen) - das geht recht geschwind, mach ich doch gleich... --Sebastian.Dietrich ✉ 07:44, 28. Nov. 2020 (CET)

Done - aber mit dem Ergebnis bin ich nicht zufrieden (Tabelle viel zu lang). Sehe 2 Alternativen:

1. Tabelle drehen - damit braucht ein Muster nicht eine eigene Zeile (sondern insgesamt gäbe es nur je Typ eine, also in Summe 6 Zeilen) - damit würden wir die Farbcodes für die Autoren verlieren, könnten das aber über Fußnoten genauso darstellen
2. Kapitel und Aufzählungen ähnlich wie in en:Software_design_pattern - damit könnten wir kurze Erklärungen reinbringen - insgesamt würde es aber viel länger und wäre keine Übersicht mehr über alle Patterns.

mMn ist die erste Lösung die bessere, die Tabelle wäre viel kompakter, könnte auch gut auf schmäleren Devices gelesen werden und würde die Autoren nicht so in den Vordergrund rücken... --Sebastian.Dietrich ✉ 08:30, 28. Nov. 2020 (CET)

Sehe ich mir an. Anmerkungen dazu bisher:

• Kommunikationsmuster ist WP:TF. Im Original heißen die en:messaging pattern, d.h. Nachrichtenübermittlungsmuster oder Datentransfermuster oder kurz, aber evtl. WP:TF, Nachrichtenmuster.
• Leere Tabellenzellen benötigen kein  .
• Die vielen leeren Tabellenzellen sehen wirklich besch...eiden aus. Ich würde die einzelnen Kategorien von Mustern in eigene Abschnitte überführen und dort nur einfache Listen, keine Tabellen machen, wie ich es für die Nachrichten-Muster mal gemacht habe. Die wesentlich einfacheren ListenTabellen haben auch den Vorteil, dass das alphabetische (ein)sortieren wesentlich einfacher ist. Im Moment ist das in den Spalten oben OK, aber weiter unten kunterbunt, weil sich die Hinzufüger die (Ein)Sortierarbeit in der Tabelle nicht antun wollten.
• Die Hauptartikel zu den Mustertypen und die Tabelle, dann die Listen, sollten aufeinander abgestimmt werden (tlw. unterschiedl. Anzahl da und dort).

--Geri, ✉  23:05, 29. Nov. 2020 (CET)

@Name - Ja da sollten wir was finden - auch z.B. Integrationsmuster (vom Titel des Buches abgeleitet). Datentransfermuster finde ich nicht so gut, da es ja nicht immer um den Transfer von _Daten_ geht.

@Aussehen - wenn wirs in einzelne (Katalog-)abschnitte unterteilen, dann mMn nicht mit Tabellen drinnen, sondern mit Definitionslisten. Wichtig wäre mir die Aufzählung aller Designpattern auf einen Blick - können wir aber auch mit der Navigationsleiste unten machen (müssen die sowieso ergänzen) --Sebastian.Dietrich ✉ 14:52, 1. Dez. 2020 (CET)

Ich hab das mal so für die Erzeugungsmuster gemacht - ist mMn besser als eine Tabelle. Ist jetzt nur Kopie aus Erzeugungsmuster, aber bei den anderen Katalogen gibt es so eine Definitionsliste nicht. --Sebastian.Dietrich ✉ 15:48, 1. Dez. 2020 (CET)

@Sebastian.Dietrich: Repliken siehe neue Abschnitte unten.

PS: Mein Disku.seiten-Symbol ist dezenter! :D --Geri, ✉  20:56, 1. Dez. 2020 (CET)

gleich geklaut :-) --Sebastian.Dietrich  ✉  18:29, 2. Dez. 2020 (CET)

Kategorien, Vorlagen

@Sebastian.Dietrich: Es gibt jetzt:

• Message (Entwurfsmuster)
• Kategorie:Enterprise Integration Patterns
• Kategorie:Vorlage:Enterprise Integration Patterns

• Vorlage:Enterprise Integration Patterns - Literatur

• Vorlage:Enterprise Integration Patterns - Internet

• Vorlage:Nachrichtenerzeugungsmuster
• Vorlage:Nachrichtenkanalmuster

...und Commons-Bilder + Kat. unten

OK so? --Geri, ✉  06:07, 5. Dez. 2020 (CET)

Ich denke, die Einteilung der EIPs auf der Seite .../patterns/messaging/toc.html ist besser als, wie bisher, auf .../patterns/messaging/index.html. --Geri, ✉  06:07, 5. Dez. 2020 (CET)

Ich melde mal vorsorglich an, dass ich aus Beobachtung aller Neuanlagen mit Befremden die Anlage folgender Seiten im Vorlagen-Namensraum beobachtet habe:

• Vorlage:Nachrichtenerzeugungsmuster
• Vorlage:Nachrichtenkanalmuster

Bei keiner der beiden dürfte es sich um Vorlagen handeln.

• Vielmehr scheint es sich um irgendwie ausgelagerte enzyklopädische Texte zu handeln.
  • Der Vorlagen-Namensraum ist keine Abwurfstelle für Quelltextblöcke, die einem zu sperrig erscheinen.
• Im Vorlagen-Namensraum stehen überhaupt keinerlei enzyklopädische Inhalte wie solch eine wegverschobene Tabelle; sondern es werden dann nur (enzyklopädische) Inhalte formatiert und zentral für die Verwendung an mehreren (!) Stellen gepflegt.
• Eine Einbindung der fraglichen Tabelle in viele weitere Artikel ist nicht absehbar; falls doch eine Mitbenutzung in einem oder wenigen anderen Artikeln vorgesehen wäre, ginge auch die abschnittsweise Einbindung aus dem umseitigen Artikel heraus.

Bitte rückgängig machen; sonst mache ich das.

VG --PerfektesChaos 15:19, 5. Dez. 2020 (CET)

@PerfektesChaos: Es sollen hier im Endausbau insgesamt 8 Vorlagen verteilt auf ca. 70 Artikel eingebunden werden. Das schien mir die effizienteste Art zu sein, um eine Vervielfachung an Arbeit und eine Vervielfachung der Anzahl der Editierorte (Stichwort: zukünftige Wartung) zu erreichen. Ich kann mich auch daran erinnern, dass das früher™ in einigen Artikeln auch schon genau so (ähnlich) gemacht wurde. Als Alternative kann ich mir vorstellen, das auf Unterseiten von Entwurfsmuster anzulegen und von dort einzubinden, wenn das geht.

So ganz kann ich das von Dir Gesagte auch nicht nachvollziehe, wenn ich mir bspw. die, beliebig herausgepickte, Vorlage:Tabelle der Jagdflugzeuge 1918 ansehe. Was ist an der so anders (außer dass sie mehr Spalten hat)? LG --Geri, ✉  18:06, 5. Dez. 2020 (CET)

Es gibt die Technologie Hilfe:Seiten einbinden #section.

• Das bedeutet: Die enzyklopädischen Tabellen kommen zurück hier in diesen oder aber einen einschlägigen Hauptartikel.
• Sie werden dort mit <section> und einem Kurzbezeichner markiert.
• Sie werden an dieser einen Stelle zentral gepflegt.
• Alle anderen Artikel, die diese Tabelle dann in vollem Umfang darstellen wollen, können sie dann mittels {{#lst:Entwurfsmuster|MarkeX}} unmittelbar anzeigen.
• Öfters wird es einem in den anderen Artikeln jedoch zu umfangreich, und die große Tabelle nervt. Dann kann auch per Verlinkung auf den Wirts-Abschnitt im Hauptartikel verwiesen werden. Und der nächste kommt an und findet, das Nachschlagen dort nervt und macht die Tabelle dann wieder direkt sichtbar. Ist mir alles egal.
• Wesentlich ist, dass diese Auslagerungen aus dem Artikelrumpf nicht im Vorlagen-Namensraum verbleiben können.

VG --PerfektesChaos 18:25, 5. Dez. 2020 (CET)

@PerfektesChaos: OK, Danke für die Info. Das mit <section> kannte ich noch nicht. Ist das erst in den letzten Jahren hinzugekommen? Ich werde das jedenfalls dann so machen. Bitte also mit Deinem Rückgängig-machen warten, bis das erledigt ist. Werde dann selber einen SLA darauf stellen.

Warum dann aber die Flugzeuge als Vorlage bestehen, ist mir immer noch nicht klar. --Geri, ✉  18:50, 5. Dez. 2020 (CET)

• „Ist das erst in den letzten Jahren hinzugekommen?“
  • „Eine Entwicklung von Ende 2012 ermöglicht“
  • Definiere: „letzten Jahren“
• Weiß nicht, wer „Flugzeuge“ ist; ich überwache seit einigen Jahren alle neu angelegten Seiten im Vorlagen-Namensraum und werde tätig, falls sich mir aus dem Namen der Vorlage kein bestimmungsgemäßer Gebrauch erschließt. Neuanlagen werden durch die VWS abgewehrt; mögliche Altbestände mag es geben und wären in einem besseren Leben zurückzubauen.

VG --PerfektesChaos 18:55, 5. Dez. 2020 (CET)

@PerfektesChaos: „...flugzeuge“ steht oben verlinkt. Nur aus dem Namen etwas ableiten zu müssen wäre gar nicht notwendig gewesen. Es stand, und steht, da überall eine Erklärung drin. Wer oder was ist VWS? --Geri, ✉  20:02, 5. Dez. 2020 (CET)

• Nachträgliche Pings wie dieser hier sind wirkungslos, weil die Erwähnung im selben Edit mit der Signatur erfolgen muss.
  • Siehe H:Echo #mention.
  • Es war sowieso sinnfrei und wäre auch im Erfolgsfall explizit unerwünscht gewesen, weil ich ja ganz offensichtlich diese Seite beobachte.
  • Hilfe:Echo #Wann sollte auf die Nutzung dieser Funktion verzichtet werden? – „In allen Diskussionen, an denen der Angesprochene sich selbst rege beteiligt, kann normalerweise auf die Erwähnung verzichtet werden“ − beachte den orange umrahmten Hinweis.
• „VWS“ ist WP:VWS.
• @ Vorlage:Tabelle der Jagdflugzeuge 1918
  • Ist von 2016.
  • Hatte mein Radar unterflogen oder ich hatte damals noch nicht 24/7 alle neu angelegten Vorlagen überwacht.
  • Es gibt keine Gleichheit im Unrecht. Alter Juristengrundsatz.
    • Heißt: Nur weil man irgendwo in über 80.000 Vorlagen eine andere findet, bei der irgendwas nicht okay ist, leitet sich daraus keine Rechtfertigung ab, es genauso zu machen.
    • Herr Autobahnpolizist, mich hat aber einer überholt, der ist sicher mehr als 200 gefahren, den haben sie nicht rausgewunken, dann dürfen sie mir aber auch keinen Strafzettel schreiben – diese Nummer läuft nicht. Versprochen.
  • In Kategorie:Vorlage:Tabelle wird es sicher zwei, drei Dutzend schwarze Schafe geben. Sind Altlasten, aber ich kenne diese Kategorie recht gut.
  • Die meisten sind jedoch sauber; etwa:
    • Vorlage:Kyrillischer Buchstabe
    • Vorlage:Darstellertabelle
    • Vorlage:NaturGeoTabelle DE
  • Entscheidend ist, dass keine eigenen enzyklopädischen Inhalte zugeliefert werden, sondern dass diese im Artikel stehen und die Vorlage nur formatiert; oder dass es sich um nachrangige Infos außerhalb des Artikelrumpfs handelt.

VG --PerfektesChaos 21:27, 5. Dez. 2020 (CET)

Danke für die Infos. Den Grundsatz kenne ich. Beispiele wie „über 80.000“ oder „Herr Autobahnpolizist“ brauchst Du nicht weiter zu bemühen. Ich kann auch darüber hinaus zählen, bin weder Idiot noch Kleinkind und außerdem ist so etwas auf einer Artikel-Disku gem. WP:DS#K 11. ohnehin sachfremd. Ich meine mich zu erinnern, dass Du in der Vergangenheit in der WP:VWS wesentlich cooler drauf warst als die letzten paar Male wo wir uns trafen. Finde ich schade. --Geri, ✉  22:05, 5. Dez. 2020 (CET)

Das mit der section war mir auch neu - coole Sache. Aber @Gerold Broser: wie kommst du auf 8 Vorlagen in 70 Artikel? Die Vorlagen/Sections brauchen wir ja nicht in den einzelnen Artikeln der einzelnen Pattern, sondern nur in den Sub-Listen. Also jede Vorlage/Section gibts nur im Hauptartikel und in einer Sub-Liste (wobei ich wie geschrieben dafür bin, das nicht zu verdoppeln sondern in den Sub-Listen ausführlicher zu schreiben). --Sebastian.Dietrich  ✉  21:09, 5. Dez. 2020 (CET)

Ich dachte, wenn wir die schon zentral und nur 1x haben, könnte es in den "Leaf"-Artikeln (des EIP-Baums) einen Abschnitt wie bspw. Weitere|Andere Pattern des Typs XYZ geben. --Geri, ✉  21:22, 5. Dez. 2020 (CET)

@Weitere Pattern des Typs XYZ - das würde ich nicht machen. Wer es bis zu einem Pattern geschafft hat kommt über die Navigationsleiste oder 1 Klick zu der Liste der Pattern des Typs XYZ. Eine Liste der ähnlichen Pattern hat für den Leser mMn keinen Vorteil. --Sebastian.Dietrich  ✉  22:05, 5. Dez. 2020 (CET)

OK. --Geri, ✉  22:23, 5. Dez. 2020 (CET)

Hauptartikel, Buch

@Sebastian.Dietrich: Analog zu:

• Entwurfsmuster
• Entwurfsmuster (Buch)

habe ich mir überlegt, ob es nicht sinnvoll wäre auch:

• Enterprise Integration Patterns
• Enterprise Integration Patterns (Buch)

ins Leben zu rufen. Was wir dann und wie detailliert und wo hin schreiben, können wir uns ja im Weiteren noch ausschnapsen. --Geri, ✉  21:19, 5. Dez. 2020 (CET)

Moin Moin Geri, ich antworte mal auf die Frage an PerfektesChaos. Die VWS ist die Vorlagenwerkstatt. (Wikipedia:VWS oder Wikipedia:WikiProjekt Vorlagen/Werkstatt) mfg --Crazy1880 21:26, 5. Dez. 2020 (CET)

Dass du auch für das Buch und die Internetquelle eine Vorlage gemacht hast gefällt mir gar nicht. Das ist mMn zu viel des DRY, reduziert die Wartbarkeit (dazu muss man sich mit Vorlagen auskennen und die verwendeten sieht man z.B. nicht wenn man nur einen Abschnitt bearbeiten) und verunmöglicht es auf bestimmte Seiten in den Büchern zu verweisen oder was zu zitieren. --Sebastian.Dietrich  ✉  22:05, 5. Dez. 2020 (CET)

Ich kannte mich mal sehr gut mit Vorlagen aus. Ich werde mich da schnell wieder zurecht finden. Man kann Vorlagen auch parametrisieren. Wenn Du das überhaupt nicht möchtest, überlasse ich es gerne Dir, die Lit., WLs und Refs in allen Artikeln einzutragen. --Geri, ✉  22:23, 5. Dez. 2020 (CET)

Ja bitte - ich mach das gerne. Ich meinte, dass sich eben nicht jeder mit Vorlagen gut/überhaupt auskennt - nicht nur du/ich schreiben an dem Artikel. Darum würde ich sie nicht für Kleinigkeiten wie Literatur etc. verwenden. --Sebastian.Dietrich  ✉  22:33, 5. Dez. 2020 (CET)

Dann bitte auch immer das Solutions in der titelerg dazuschreiben. --Geri, ✉  00:24, 6. Dez. 2020 (CET)

PS: Wobei, eigentlich hätte ich Dich das 210+ mal ohne eintragen lassen sollen, dann hättest Du vielleicht die Vorzüge von DRY noch viel mehr zu schätzen gewusst. :D LG --Geri, ✉  01:38, 6. Dez. 2020 (CET)

Sicher :-) Versteh aber nicht, was du eigentlich meinst - in der titelerg steht ja schon solutions drinnen - Gregor Hohpe, Bobby Woolf: Enterprise Integration Patterns. Designing, Building and Deploying Messaging Solutions. Hrsg.: Addison-Wesley. 1. Auflage. Addison-Wesley, 2003, ISBN 978-0-321-20068-6 (englisch, 480 S.). 

Ja, das steht jetzt drin, weil ich es dann überall nachgetragen habe. :)

Und wenn Du mir sagst, was Du alles ändern können möchtest, dann kann ich bei Refs. (und auch WLs) daraus Parameter machen, damit eine richtige Vorlage, die als solche bestehen bleiben könnte. Lit. wird sich ja nie mehr ändern (außer die Außerirdischen geben sich endlich zu erkennen und wir müssen daraufhin eine USBN einführen. :) --Geri, ✉  17:23, 6. Dez. 2020 (CET)

Warum nahmst Du meinen Kommentar auch mit raus? --Geri, ✉  18:26, 6. Dez. 2020 (CET)

Sorry habe ich nicht absichtlich getan. Siehe dazu aber auch mein Kommentar unten bei den Refs... --Sebastian.Dietrich  ✉  19:10, 8. Dez. 2020 (CET)

@Buch - ich denke nicht, dass wir das jetzt schon machen sollten. Das EIP-Buch hatte weit weniger Einfluss als das DesignPatterns Buch, wüsste gar nicht was man zum Buch alleine schreiben sollte. Da sollten wir unsere Energien mehr in die Beschreibung der Patterns (auch der anderen noch fehlenden Patterns) stecken. Wobei Patterns per se auch nicht mehr so wichtig = gehyped sind wie in den 90er/0er Jahren. --Sebastian.Dietrich  ✉  22:05, 5. Dez. 2020 (CET)

OK, dann das Buch nicht, aber wenigstens den HA? --Geri, ✉  22:23, 5. Dez. 2020 (CET)

BTW, sind die Einrückungen beim Antworten in Diskus irgendwie aus der Mode gekommen? Fiel mir schon anderswo bei P.C. hier und jetzt auch bei Dir auf. --Geri, ✉  22:26, 5. Dez. 2020 (CET)

Ich rücke immer ein (es sei denn ich vergesse es), auf die Ebene auf die ich antworte. Ist aber auch keine perfekte Lösung, da 1) zu viele Einrückungen hässlich sind und 2) man dann oft nicht mehr weiß, auf was ich denn eigentlich antworte.

Hauptartikel auf jeden Fall - wäre sonst die einzige Patternkategorie, die keinen Hauptartikel hat... --Sebastian.Dietrich  ✉  22:30, 5. Dez. 2020 (CET)

@Sebastian.Dietrich: Möchtest Du Deinen Beitragzähler erhöhen? :) Volle Refs im Fließtext sind extrem mühsam beim Editieren, da sie den Wikitext sehr unübersichtlich machen. Seien wir doch froh, dass es eine höchst elegante Alternative dazu gibt. Ich nutze ausschließlich diese, immer. --Geri, ✉  21:08, 7. Dez. 2020 (CET)

@Gerold Broser:Scherzkeks - wennst genau schaust, siehst auch dass der Einzelnachweis durch Seitenangaben ergänzt wurde.

Ich bin da anderer Meinung und habe es bisher noch nirgendwo so gesehen, wie du das handhabst. Es ist aber beides möglich / erlaubt (siehe H:REF). Der Nachteil, dass der Fließtext dann schlechter lesbar ist, wird mMn dadurch mehr als wettgemacht, dass man 1) keine oft undurchschaubaren Abkürzungen für die Ref-Namen braucht (bei Dingen, die nur 1x referenziert werden), 2) die Refs dort schreibt, wo sie hingehören (und auch löscht, was bei deiner Technik leicht zu nicht mehr referenzierten Einzelnachweisen führt), 3) man einen Abschnitt editieren kann und nicht auch mehr oder weniger gleichzeitig den Einzelnachweise-Abschnitt und 4) dass das in anderen nicht-wysiwyg Editoren auch so gehandhabt wird (z.b. in LaTeX). --Sebastian.Dietrich  ✉  19:10, 8. Dez. 2020 (CET)

@Sebastian.Dietrich: Ja. Eh. Drum ist ja auch ein Smiley hinten dran – wird ein Absatz komplett verschoben, sieht man das nicht mehr extra im Diff. markiert.

Gut, Kompromiss-/Konsensvorschlag: Wenn Du den Fließtext verschmutzen möchtest ;), gerne, ich lasse das dann so. Wenn ich das anders mache, bitte nicht "editvergeudend" umändern. Geht das? Morgen? LG --Geri, ✉  20:43, 8. Dez. 2020 (CET)

Beispielcode

@Sebastian.Dietrich: Was sagst Du zu dem Code in Message (Entwurfsmuster)? --Geri, ✉  22:37, 5. Dez. 2020 (CET)

Ich mag Code in Wikipedia Artikel prinzipiell nicht - bin also da der falsche Ansprechpartner. Warum: Weil der meist zu lang ist um das Thema zu veranschaulichen und den Lesefluss stört, da andere Sprache. Also so wie ewiglange Zitate in einer anderen Sprache.

Der vorliegende Code passt aber nicht zum Pattern - Message im Sinne von EIP hat keine main Methode, keine transmit und keine restore Methode, sondern nur einen header und einen body. Der korrekte Code wäre mMn

public class Message implements Serializable {
    private final MessageHeader header;
    private final MessageBody body;
 
    public Message (MessageHeader header, MessageBody body) {
        this.header = header;
        this.body = body;
    }
}

das wäre von der Länge her mMn gerade noch verträglich - aber da bin ich wie gesagt pingelig. --Sebastian.Dietrich  ✉  14:29, 6. Dez. 2020 (CET)

@Sebastian.Dietrich: Die Artikel zu den einzelnen Patterns sind eh nur sehr kurz und werden auch in zig Jahren nicht, vulgo nie, viel länger sein. Des is mei Extra! :) Wenn irgendjemand – musst ja nicht unbedingt Du sein – "mir", eigentlich der WP, diesen Code rausreklamiert, dann war's das hier für mich. Ich habe überhaupt keine Lust dazu, hier Stunden, Tage, Wochen und Monate zu investieren und dann kommt eine/r daher und drischt mit ihrem/seinem Schauferl auf die Sandburg in der Nebensandkiste. (Der Code von den bestehenden, bspw., hat zwei Nachtschichten benötigt und, wenn, dann wird das so weitergehen, da ich Camel jetzt auch (noch) nicht aus dem Effeff beherrsche – aber mit der Zeit weniger aufwändig werden, da ich sehr rasch dazulerne). Dann muss halt wer Anderer die 70+ Artikel hier anlegen und die 140+ Commons-Bilder hochladen. OK, die Programmierung ersparte er/sie sich dann...^</sarcasm>

Was ist das für eine Library? Was ist das für ein Package dort? Wo hast Du das her? ...Ach so, das hast Du missverstanden, das ist keine Message-Implementierung, sondern ein Beispiel, wie man eine solche verwendet. Steht eigentlich eh genau darüber: „Im folgenden Beispielcode in Java wird die DSL von Apache Camel<ref name="Camel-Java-DSL" /> [Anm.: Das ist eine solche Implementierung.] verwendet, das auf Enterprise Integration Patterns basiert.“

Ich bin auch pingelig. In der WP, was Belege, NPOV, Relevanz, Vollständigkeit, Umfang an Infos (möglichst viel), Richtigkeit, Grammatik, Satzbau, UX-Design, einfache Bearbeitung etc. betrifft.

Es gibt Neues: Document Message. :) LG --Geri, ✉  16:05, 6. Dez. 2020 (CET)

Der Code ist aber auch bei Document Message mMn falsch am Platz. Der Code zeigt, wie man eine Document Message in Apache Camel verwendet, aber nicht wie man eine schreibt. Das wäre so, wie wenn man bei Iterator (Entwurfsmuster)#Beispiel nicht zeigen würde, wie man einen Iterator schreibt, sondern nur wie man ihn verwendet. Dafür ca. 70% des Artikels zu reservieren ist mMn falsch. Wenn ich mich für das Pattern Document Message interessiere, dann nicht, wie ich in Apache Camel eine solche schicke, sondern wie das Pattern beispielhaft zu implementieren ist. --Sebastian.Dietrich  ✉  21:15, 6. Dez. 2020 (CET)

Wie viele Entwickler entwicklen Frameworks mit Messages, Document Messages etc. und wie viele verwenden diese? „ca. 70% des Artikels zu reservieren“?!? Haben die WP-Server mittlerweile doch Platzprobleme auf ihren HDDs? „Wenn ich mich für ... interessiere“ – genau, ich ist das Schlüsselwort. Ich wiederum bin ausschließlich daran interessiert, wie ein Framework umgesetzt ist und wie man es verwendet. Ich werde für den Rest meines Lebens sicher nicht mehr in die Verlegenheit kommen, eins zu schreiben. Da gibt es weitaus Berufenere und die haben bzw. holen sich das dazu benötigte Wissen sicher nicht aus der WP.

Wir können ja den sowohl als auch-Ansatz wählen. Somit halte ich Deine Idee – zur Hälfte – sogar für eine sehr gute. Es steht dann doppelt so viel Info in der WP. Von daher, leg los, füg Beispiel-Implementierungen hinzu. Dein Fragment von oben habe ich in Message (Entwurfsmuster) schon mal eingefügt. --Geri, ✉  22:03, 6. Dez. 2020 (CET)

PS: Persönliche Anmerkung: Sich dazu bereit zu erklären, 70+ Artikel neu zu schrieben + bestehende zu erweitern und 140+ Commons-Bilder hochzuladen, und das alles aus dem Englischen, also nicht bloß abschreiben und umformulieren, sondern aufwändiges Nicht-1:1-Übersetzen von Idiomen Phrasen, Fachbegriffen etc., oder zumindest dabei aktiv mitzutun, obwohl ich das anfangs gar nicht vorhatte bzw. wollte, und dann – jetzt nur mal in diesem Abschnitt – zu lesen „Ich mag [das] nicht“,„passt aber nicht“, „falsch am Platz“, „ist mMn falsch“ hat mir ein wenig zu viele Iche und Nichte drin. Für mich ist so etwas nicht motivierend. Wie sieht es da bei Dir aus? Wäre es das für Dich? --Geri, ✉  22:19, 6. Dez. 2020 (CET)

Ich denke du nimmst das zu persönlich. Ich verstehe, dass du deine Arbeit (= "dein Baby") schützen möchtest und negative Aussagen über einen Teil davon demotivierend findest. Es geht aber wirklich nur um einen Teil von deiner Arbeit (den Code) - alles andere (70+ Artikel neu schrieben + bestehende zu erweitern und 140+ Commons-Bilder hochladen, ...) wird von mir gar nicht bekrittelt. Danke auf jeden Fall dafür - ich denke du machst da sehr gute Arbeit.

WP ist aber ein Gemeinschaftswerk - wir haben quasi collective code-ownership. Alles was du oder ich schreibe kann und sollte von jedem bekrittelt, verändert, ergänzt oder auch gelöscht werden, wenn es die Qualität der Artikel verbessert. Ich hab schon 70+ Artikel geschrieben, da ist schon jede Menge bekrittelt, verändert, ergänzt oder auch gelöscht worden und ich bin froh darüber, da insgesamt die Qualität dadurch gestiegen ist und die Sicht auf ein Thema weniger einseitig wurde. Wichtig ist dabei nur, dass man auf einen Konsens kommt, der allen passt. Solange die Diskussionen die Verbesserung der Artikel im Sinn haben und nicht durch Befindlichkeiten, Untergriffigkeiten etc. gestört werden sind sie für mich auch nicht demotivierend.

Konsens strebe auch ich hier an. Wenn du der Meinung bist, dass die Verwendung eines Pattern codemäßig repräsentiert werden sollte und ich der Meinung bin, dass die Implementierung eines Pattern codemäßig repräsentiert werden sollte, dann ist "beides" ein guter Konsens.

Aber wenn ich mir deinen Code ansehe bzw. deine Aussage oben, dann bist du gar nicht der Meinung, dass die Verwendung eines Pattern codemäßig repräsentiert werden sollte, sondern "wie ein Framework (= Camel) [dass u.A. das Pattern implementiert hat] zu verwenden ist". Stimmt das?

Wenn ja, dann sehe ich da folgende Kritikpunkte:

* Ist es auch sicher, dass Camel tatsächlich das Pattern so wie im Buch beschrieben (mit Ergänzungen etc.) implementiert hat? Lt. Buch braucht eine Message zumindest einen Header und einen Body - gibts das tatsächlich bei Camel? Im Code erkenne ich nur den Body. Kann man den Header überhaupt irgendwie im Code sichtbar machen? Oder ist Camel nur ein Framework mit dem man Messages, die gar nicht dem Message Pattern entsprechen, verschicken kann?

* Wäre der Code dann nicht besser (oder zusätzlich) in Apache Camel aufgehoben? Im Code haben gerade mal 2 Statements was mit dem Message-Pattern zu tun (m -> m.setBody( text ) und m.getBody()), der Rest ist die Verwendung von anderen Pattern bzw. von Camel bzw. der DSL von Camel.

* Was machen wir mit den vielen anderen Pattern, die vielleicht intern in Camel implementiert sind, aber für den Verwender des Frameworks nicht sichtbar sind? Ich vermute das wird ein Großteil der EIPs sein. D.h. es ist unmöglich Code zu schreiben, der die Verwendung des Pattern X in Apache Camel zeigt. Kein Code oder Code, der nichts mit dem Pattern zu tun hat und wo nur behauptet wird, dass im Hintergrund das Pattern verwendet wird?

* Wird durch die große Menge des Sourcecodes dann nicht der Fokus des Lesers vom Lemma selbst weg und auf Apache Camel bzw. die DSL von Camel verschoben, wenn 70% des Artikels gar nicht das Lemma selbst behandeln (es geht um den Leser, nicht um den Speicherplatz der Wikipedia)

Wenn nicht die Verwendung von Camel im Vordergrund stehen soll, sondern die Verwendung des Pattern (so wie es Apache Camel zur Verfügung stellt), dann würde ich vorschlagen den Code hier auch auf das für den Artikel Wesentliche mit möglichst wenig Code rundherum (muss ja nicht compilieren) zu reduzieren. Also das setBody und eventuell irgendwas mit dem Header und kaum was rundherum. "Mein" Code zur Implementierung des MessagePatterns beschränkt sich auch auf die drei Dinge 1) serialisierbar, 2) header, 3) body.

...
public class ApacheCamelMessageSenderExample {
    private static final DefaultCamelContext cc = new DefaultCamelContext();
    ...
    private static void transmit( final String text ) throws Exception {
        cc.addRoutes( new RouteBuilder() {
            @Override
            public void configure() {
                from( "timer:start?repeatCount=1" )
                    .process()
                    .message( m -> m.setBody( text ) ) //Apache Camel Message wird hier mit text im Body befüllt
                    .to( "direct:receive" )
                    .setId( "send" );
            }
        });
    }
    ...
}

--Sebastian.Dietrich  ✉  08:09, 7. Dez. 2020 (CET)

1. Ad „dann ist "beides" ein guter Konsens“ – Passt, sehe ich auch so. Gilt der damit hiermit als vereinbart?

2. Ad „Ist es auch sicher, dass Camel tatsächlich ...“ – Bitte informiere Dich (selbst, idealerweise vorher):

2.1. Erster Satz im Apache Camel User Manual: „Apache Camel™ is a versatile open-source integration framework based on known Enterprise Integration Patterns.“

Erster Satz unter dem ersten Link: „Camel supports most of the Enterprise Integration Patterns from the excellent book by Gregor Hohpe and Bobby Woolf.“

2.2. Ad „Header, Body“: org.apache.camel.Message. Ich kann auch Header und Body im Verw.-Code setzen, ÜKP.

3. Ad „Wäre der Code dann nicht besser (oder zusätzlich) in Apache Camel aufgehoben?“ – Sicher, wenn es Dir nichts ausmacht, dass dann 99 % jenes Artikels aus Code bestehen, bei 65- Patterns...

4. Ad „auf das für den Artikel Wesentliche mit möglichst wenig Code rundherum“ – Ich hasse es, überall im Netz, wenn ich da Code-Beispiele finde, wo für Java so wesentliche Dinge wie imports oder Variablen-/Methodendeklaration und Kommentare, warum man gerade diese Klasse/Methode verwendete etc. fehlen, weil es ja nur um „das für den Artikel Wesentliche“ geht.

LG. --Geri, ✉  11:44, 7. Dez. 2020 (CET)

1. Ja machen wir beides.

2. Danke für die Info, habe sie jetzt dort nachgetragen, wo sie sein sollte ("schau selber nach" gibts in der WP nicht :-))

2.2. "ÜKP" verstehe ich nicht. Wäre toll, wenn auch der Body im Verwendungscode gesetzt oder was auch immer wird. Dann sieht man besser, dass hier eine EIP Message verwendet wird.

3. Was ich meinte ist, dass wenn die Verwendung von Camel im Vordergrund steht, dann sollte der Code _ausschließlich_ im Artikel Camel stehen. Derzeit ist das mMn der Fall (siehe nächster Punkt)

4. Wir sind hier in der WP nicht irgendwo im Internet. Die WP versteht sich als Enzyklopädie, da ist das für den Artikel Irrelevante auf ein Minimum zu halten. Für Java ist genauso wichtig, dass man Java installiert, eine IDE hat, und die Library in den Build einbindet. Wenn wer das alles zu deinem Code dazuschreiben würde, dann wärst du vermutlich auch nicht glücklich damit.

Darum nochmal die Frage: "Geht es dir um die Verwendung von Camel oder um die Verwendung des Message Patterns?". Wenn ersteres, dann gehört der Code weitaus ergänzt (um andere Features von Camel) und in den Apache Camel Artikel verschoben. Wenn zweiteres, dann auf das Wesentliche reduziert so wie ich es oben beispielhaft gemacht habe. --Sebastian.Dietrich  ✉  18:26, 8. Dez. 2020 (CET)

2. Wir sind hier auf einer AD-Seite. Ich möchte nicht immer alles für andere ausgraben, verlinken, zitieren etc. müssen. Da appelliere ich, ganz so wie aktuell bei Corona, an die Eigenverantwortung. :-))

2.2. Überhaupt kein Problem. (Zugegeben, das war nicht leicht zu erraten. Kennst Du: „If you cannot convince them, confuse them!“? :))

Kann ich machen, bringt aber keinen Mehrwert. Die Command Message bspw. hat nur eine Info zur RPI zum Inhalt: getLastTradePrice("DIS");. Die kann jetzt in Header-Feldern stehen: command="getLastTradePrice", args="DIS" oder als String, Map, List, XY-Objekt im Body. (Pfff, ich muss [mich] schon wieder lang und breit erklären...das kostet Zeit!) Ich weiß was ich tue und ich tue die Dinge, die ich tue, wohlüberlegt und möglichst präzise. Du kannst mir da voll und ganz vertrauen. Kontrolle ist auch gut. Wenn Du nachher drüber schaust, weiß ich das zu schätzen.

3. Nein, tut sie nicht. (siehe nächster Punkt)

4. Du baust hier Strohmänner auf. Ich kenne und erkenne das. Das zieht bei mir als Argument nicht. Lass es bitte. Niemand sprach je von absoluter, ja nicht mal annähernder Vollständigkeit, weil wir dann letztendlich beim Urknall landen würden.

(Ich liebe die Physik und die Astronomie bzw. Kosmologie im Speziellen [habe das sogar studiert], aber das führte dann doch zu weit.)

Kompromiss ist das Schlüsselwort (zwischen der Würze der Kürze und vollständiger Vollständigkeit): So wenig wie möglich, so viel wie nötig. Ich habe mich im Verw.-Code auf das Notwendigste beschränkt. Knapper geht es nicht, ohne wesentliche Information zu verlieren.

Warum siehst Du das so exklusiv? Ich halte es lieber inklusiv: Ein Beispiel einer Verwendung des Message Patterns anhand der (inoffiziellen, quasi) Referenzimplementierung Apache Camel. Ist das OK für Dich?

5. Dein Beispiel-Code ist halb sehr schlecht. Er bildet nur die Hälfte des Messaging-Prozesses ab: Das Senden. Der Name der Klasse ist auch schlecht, weil es nicht um ApacheCamel... geht. (Aber das war Dir da offenbar noch nicht vollkommen klar.) ...Example ist auch schlecht, weil die Klasse eine echte, real funktionierende Message repräsentieren soll, der Du dann die OO-Nachricht message.transmit(); senden kannst (wenn man sie mind. default (=package) access macht).

LG --Geri, ✉  21:11, 8. Dez. 2020 (CET)

Definitionslisten ggü. Tabellen

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. Die geplanten Erweiterung werden in Summe länger als der Archivierungs-Threshold dauern und damit das alles nachvollziehbar bleibt...

Wusste nicht, dass die Def.listen so genannt werden (man lernt nie aus :)(WIMRE waren Einrückungen mit „:“ in Artikeln mal verpönt. Hab' aber eine längere Wikipause hinter mir.), sehen auch OK aus. Der Nachteil: Sie sind nicht dreifach sortierbar: alphabetisch ab/auf und wie im Original.

Bei den EIP folgt die Reihenfolge dort einem semantisch-/didaktischen Aufbau, bspw.: Message als erstes, dann Arten von M.s, dann das was M.s enthalten können. Alphabetisch sortiert ist besser für die Suche nach einem bestimmten Muster. Mit einer Tabelle hätte man beides.

Und: Die Kopiervorlage in Definitionslisten ist m.E. ungünstig. Wenn man vor den Pseudo-ÜSen Leerzeilen einfügt, sind die Zeilenabstände einen Tick größer und damit alles optisch schöner und leichter lesbar. Vgl. jetzt mal erste und letzte drei in Entwurfsmuster#Erzeugungsmuster. --Geri, ✉  21:16, 1. Dez. 2020 (CET)

@Sebastian.Dietrich: Ist das auch für Dich OK mit den Tabellen, weil dann würde ich die restlichen Muster auch aus der großen rausziehen. --Geri, ✉  21:21, 2. Dez. 2020 (CET)

@Gerold Broser: Ja passt - ist wohl die beste Lösung, wenn man zu den Patterns was dazuschreiben möchte. Alternativ dazu reicht mMn auch die Navigationsleiste - ich kümmere mich mal um die Navileiste... --Sebastian.Dietrich  ✉  11:41, 3. Dez. 2020 (CET)

@Sebastian.Dietrich: Nur Navi-Leiste reicht nicht. Erinnere mich dunkel, dass es dazu irgendwo auch eine Richtlinie gab/gibt. Die ist ganz am Ende, meist auch erst mal eingeklappt und ohne Kurzbeschreibung der darin enthaltenen Links. --Geri, ✉  18:22, 3. Dez. 2020 (CET)

Ok passt - dann machen wir die Abschnitte mit den Tabellen statt der einen großen Tabelle. In den Hauptartikeln dann Definitionslisten so wie schon bei Verhaltensmuster und Erzeugungsmuster. --Sebastian.Dietrich  ✉  06:57, 4. Dez. 2020 (CET)

Sieh Dir mal (bis jetzt, kommen natürl. noch mehr) Vorlage:Nachrichtenerzeugungsmuster & Vorlage:Nachrichtenkanalmuster an. Und dann die entspr. Abschnitte im Artikel hier im Edit-Mode. Ich hatte mir vorgestellt, die in den HAn auch so einzubinden, ganz gem. DRY. Ist Dir das kleine, unscheinbare Einstellungen-Symbol in den Kopfzeilen rechts oben aufgefallen? Klick mal drauf... :)) --Geri, ✉  21:30, 4. Dez. 2020 (CET)

Das mit den Vorlagen hab ich schon gestern gesehen - sehr cool (das mit dem Einstellungen-Symbol). ABER: Ich denke nicht, dass es gut ist, die Abschnitte hier und in den Spezialartikeln zu wiederholen. Hier sollte mMn nur kurz (auf normaler Bildschirmbreite max. 1 Zeile) das Pattern erklärt werden, in den Spezialartikeln dann mMn etwas länger via Definitionsliste. Von DRY halte ich im Code sehr viel aber in einem Nachschlagewerk eher weniger (bis auf Navigationsleisten oder ähnliches "technisches" Zeugs). Fände ich als Leser komisch, wenn ich von diesem Artikel auf den Spezialartikel komme und dort steht dann 1:1 dasselbe in dem Aufzählungsabschnitt (und viel mehr haben die Spezialartikel dann auch nicht) --Sebastian.Dietrich  ✉  13:19, 5. Dez. 2020 (CET)

Seit gestern hasse ich Def.listen offiziell: Hilfe_Diskussion:Listen#Grundformen. (Und nein, nicht aufgrund der @§$%&! dort.) Man sollte/darf darin die Zeilenabstände nicht verändern. So aneinandergepickt sieht das echt besch...eiden aus. --Geri, ✉  18:29, 5. Dez. 2020 (CET)

Finde ich nicht - im Gegenteil, mir gefallen sie weit besser als Tabellen mit nur Definition/Erklärungsspalten. Aber das ist halt Geschmacksache... Aber egal - hier im Hauptartikel haben wir uns mal auf die Listen geeinigt (weil sortierbar, farblich gestaltbar und Erklärung auf ein kurzes Satzerl beschränkt) --Sebastian.Dietrich  ✉  21:02, 5. Dez. 2020 (CET)

Wie jetzt genau? ▪ Listen (eigentlich Aufzählungen), Def.listen oder doch Tabellen? Mit Aufzählungen (dann alphabet. aufsteigend) könnte ich leben (dann ohne 3-fach-Sortierung). Def.listen, wie erwähnt, sehen hässlich aus. --Geri, ✉  23:10, 5. Dez. 2020 (CET)

PS: Sollte irgendwer dem Artikel diese @§$%&! Def.listen aufs Auge drücken wollen, bin ich auch raus. Die Aufzählungen haben nämlich genau das, was ich bei den Def.listen als bemängelten Mangel bemängelte: unterschiedliche Zeilenabstände inner- und außerhalb der Aufzählungspunkte. Die Aufzählungszeichen am Beginn sehen auch nett aus. --Geri, ✉  20:36, 6. Dez. 2020 (CET)

Sorry, meinte Tabellen, also dass wir uns auf Tabellen geeinigt hätten (weil sortierbar, farblich gestaltbar und Erklärung auf ein kurzes Satzerl beschränkt). Ist von den drei Möglichkeiten mMn (und so wie ich dich verstanden habe auch dMn) die beste. Lieber wäre mir gar nix, also nur eine Tabelle mit den Namen (so wie bisher nur um 90 Grad gedreht) - weil mit den vielen Tabellen wird der Artikel nicht wirklich hübsch. Andererseits ohne kurzes Satzerl zu den einzelnen Patterns weiss man gar nicht welches der vielen Pattern was macht. Also mMn hässlich aber sinnvoll :-)

@PS - geh hör doch auf mit "dann bin ich raus" zu drohen. Das wird niemanden abschrecken irgendwas zu tun, was dir nicht passt.--Sebastian.Dietrich  ✉  18:07, 8. Dez. 2020 (CET)

Wie gesagt, mit Aufzählungen könnte ich auch sehr gut leben. Die sehen auch nicht so (er)drückend aus wie, insbesondere eingefärbte, Tabellen. Wenn Tabellen, dann plädiere ich für schlichte Eleganz, ohne kräftige oder gar schreiende Farben, am besten WP-Standard wie derzeit die ersten 6.

PS: Ja, ich höre gerne damit auf (nach eh erst 2x). Das ist/war nicht als Drohung gedacht, sondern als Ausdruck meiner persönlich Konsequenz, wenn ich den Eindruck gewinne, dass ich meine Zeit hier verplemper[e|n muss]. --Geri, ✉  21:44, 8. Dez. 2020 (CET)

EIP Bebilderung

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. Die geplanten Erweiterung werden in Summe länger als der Archivierungs-Threshold dauern und damit das alles nachvollziehbar bleibt...

@Sebastian.Dietrich: Super News! Wir haben (bald) auch Bilder --Geri, ✉  01:31, 5. Dez. 2020 (CET)

Es gibt jetzt: commons:Category:Enterprise integration patterns

Hast Du eine Idee, warum das ...px beim ersten Bild auf Message (Entwurfsmuster) nicht funktioniert? --Geri, ✉  08:23, 5. Dez. 2020 (CET)

Toll :-) - das mit dem px liegt irgendwie am Rahmen, ohne Rahmen funkts, hat aber dann keine Beschreibung. --Sebastian.Dietrich  ✉  13:23, 5. Dez. 2020 (CET)

Bei mir funkt es ohne gerahmt auch nicht. Hab mal x999px eingetragen und das Bild ist immer noch so klein. Ratlos. --Geri, ✉  18:33, 5. Dez. 2020 (CET)

Wikipedia:Redaktion Bilder#Message (Entwurfsmuster) --Geri, ✉  22:08, 5. Dez. 2020 (CET)

Übergewichtung Nachrichtenübermittlungsmustern / Qualität des Artikels

Mitte letzten Jahres ging es in diesem Artikel noch um eine Übersicht zu Entwurfsmustern in der Software-Entwicklung. Nun gibt es mehr Text nur zu Nachrichtenübermittlungsmustern als bisher zum relevanten "Rest". Ich möchte eine eigene Seite zum Thema Nachrichtenübermittlungsmustern vorschlagen. Als Einstieg zum Thema Entwurfsmuster in der Software-Entwicklung ist diese Seite IMHO nicht mehr zu gebrauchen. --72er (Diskussion) 12:29, 1. Mär. 2021 (CET)

Die (in der Software-Entwicklung) relevanten Entwurfsmuster sollten vielleicht einen eigenen Artikel Entwurfsmuster (Software) und die Nachrichtenübermittlungsmustern einen anderen Entwurfsmuster (Nachrichten) bekommen. Außerdem sind viele Nachrichtenmuster ohne Beschreibungen aufgelistet in halbleeren Tabellen. --72er (Diskussion) 19:17, 1. Jun. 2021 (CEST)

Bin beinahe ganz @72er:s Meinung - da ist was angefangen worden und nicht fertiggestellt worden. Ich würde aber nicht zwischen Entwurfsmuster (Software) und Entwurfsmuster (Nachrichten) unterscheiden, das wäre TF, Nachrichtenübermittlungsmuster sind genauso ein Teilbereich der Entwurfsmuster wie z.B. Erzeugungsmuster. mMn solle folgendes gemacht werden bzw. kann ich das auch übernehmen:

• Eigene Seite zu Nachrichtenübermittlungsmuster, Übertrag der (wenn vorhandenen) Infos auf diese Seite
• Entfernung der Aufzählung, Tabellen etc. der einzelnen (Teil-)Musterkataloge, Übertrag der (wenn nicht doppelten) Infos auf die Hauptartikel
• Je (Teil-)Musterkatalog nur Referenz auf Hauptartikel und je einen Absatz

--Sebastian.Dietrich  ✉  08:43, 2. Jun. 2021 (CEST)

Nachdem es dazu keine Rückmeldung gab, gehe ich die Änderungen jetzt an... --Sebastian.Dietrich  ✉  08:48, 18. Jun. 2021 (CEST)

Architektur Vs. Software-Architektur

Mir erschließt sich nicht, was Software-Entwurfsmuster mit Haus- oder Brückenbau zu tun haben sollen. Ich sehe eigentlich 2 Themen, die nur (mehr oder weniger) zufällig denselben Namen haben. --85.199.68.80 12:52, 7. Jun. 2021 (CEST)

Was meinst du damit? Vielleicht den Satz in der Einleitung "Ursprünglich wurde der Begriff in der Architektur von Christopher Alexander verwendet.[1]"? Der sagt ja nur, dass der Begriff "Pattern" aus der Architektur stammt - d.h. nicht "zufällig denselben Namen haben" sondern "bewusst wurde der bereits etablierte Name für was neues verwendet". --Sebastian.Dietrich  ✉  07:06, 8. Jun. 2021 (CEST)

So isses.

Die IT, zunächst als EDV, kam neu auf und bediente sich bei ihren Metaphern und Strategien an bereits existierenden Vorgehensweisen in der Technik usw.

Architekten werden Musterlösungen für Treppen, Treppenräume usw. haben; für verschiedene Typen einer Hotel-Lobby und mehr.

VG --PerfektesChaos 18:41, 13. Jun. 2021 (CEST)

Ich hab das Buch von Christopher Alexander selbst daheim - ist sehr interessant und tatsächlich ähnlich zum Design Patterns Buch. Da werden viele (ich glaub >100) Patterns von kleinen Dingen der Innenarchitektur ("Different Chairs") bis große Dinge der Stadtplanung ("Sunny side of the street") vorgestellt - immer auf die gleiche Art und Weise (Name, was ist damit gemeint, Beispiele, wo sinnvoll, wo nicht, ...). Die GoF haben da mMn exakt die richtige Vorlage und somit auch exakt den richtigen Namen gewählt - Hut ab. --Sebastian.Dietrich  ✉  09:08, 14. Jun. 2021 (CEST)