Diskussion:Anti-Pattern

message: === Theoriedarstellung ===
Sehr wenige aufgeführte, einzelne Anti-Pattern lassen sich ambivalent bezüglich der Wikipedia:Theoriefindung diskutieren. Das ist damit zu begründen, dass teilweise wichtige Anti-Pattern leider uneinheitlich benannt werden. Relevante Einzelfälle hier im Anschluss: --Fasten 20:37, 1. Jun 2006 (CEST)
thread_title:  Anmerkungen zum Artikel 

message: Sehr wenige aufgeführte, einzelne Anti-Pattern lassen sich ambivalent bezüglich der Wikipedia:Theoriefindung diskutieren. Das ist damit zu begründen, dass teilweise wichtige Anti-Pattern leider uneinheitlich benannt werden. Relevante Einzelfälle hier im Anschluss: --Fasten 20:37, 1. Jun 2006 (CEST)
thread_title:  Theoriedarstellung 

message: Hi, meiner Meinung nach muss das „p“ im Lemma groß geschrieben werden, also „Anti-Pattern“. Das geht für mich aus § 55 der amtlichen Regelung hervor, genauer Absatz 3 auf Seite 55: „Substantivische Bestandteile werden auch im Innern mehrteiliger Fügungen großgeschrieben, die als Ganzes die Funktion eines Substantivs haben…“ --jpp ?! 14:03, 9. Mai 2006 (CEST)
replies: text: ok, überredet. :-) danke, dass Du das schon angepasst hast. --Michael Hüttermann 14:10, 9. Mai 2006 (CEST)
thread_title:  Großschreibung des Lemmas 

message: Hallo Fabian. Lavafluss: meines Wissens nach dreht sich das Anti-Pattern um "dead code", also code der irgendwo rumhängt, aber nicht mehr genutzt wird. Und das Ganze mit zunehmender Quantität im Laufe des Produktlebens. Gibt es irgendwo eine anderslautende Definition? --Michael Hüttermann 23:31, 16. Mai 2006 (CEST)
replies: text: Ich habe bis auf weiteres den Lavafluss inhaltlich auf die in der Literatur beschriebene Definition angepasst. Hier sollten wir nochmal klären ob Dein Anti-Pattern auch unter dem Begriff Lavafluss positioniert werden sollte. Für mich ist das eher ein anders, sehr weit verbreitetes Pattern, über dessen Namen ich mir im Moment nicht im klaren bin. --Michael Hüttermann 15:12, 20. Mai 2006 (CEST)
thread_title:  Lavafluss 

message: Der Text ähnelt . Das ist außerdem der einzige andere Treffer auf google für diesen Begriff. Das hat in einer Enzyklopädie wohl nicht verloren. --Fasten 16:38, 19. Mai 2006 (CEST)
replies: text:  Siehe bitte meine Diskussionsausführungen unten zum Thema Faux System Architect. "Programmer Experience Clumping" ist sowas von weit verbreitet.....es musste nur jemand wie Eckel vorangehen, um dem Kind einen Namen zu geben. Ich habe das konkrete Muster mit meinen eigenen Worten geschrieben und mit meinen eigenen, persönlichen Erfahrungen angereichert....abgerundet mit der Referenz auf den Artikel von Eckel.--Michael Hüttermann 15:05, 20. Mai 2006 (CEST)
replies: text:  Es ist so verbreitet, daß es eigentlich nichts mit Informatik zu tun hat. Das Pattern ist sicher auch bei Ghetto - und Cliquenbildung jeder Art zu beobachten: Eine oder mehrere Gruppen ziehen sich aus einem Bereich zurück und die Restgruppe ist anschließend charakteristisch für die Abwesenheit der Mitglieder dieser Gruppen. Ich würde z.B. auch den Fischteicheffekt in dem Kontext erwähnen. Wenn es aber nur einen Autor gibt der das Pattern so nennt fehlt da nicht die Grundlage für eine Erwähnung in der Wikipedia? --Fasten 19:10, 20. Mai 2006 (CEST)
replies: text:  Hallo Fasten. Danke für Deine kritische Auseinandersetzung. Anti-Pattern reduzieren sich nicht nur auf die klassische Programmierung. Es gibt eben auch organisatorische und management-orientierte Anti-Pattern. Schau Dir dazu alleine mal die Werke von Tom DeMarco an. Er schreibt auch über genau diese Thematik - nur benennt er das nicht explizit. Fischteicheffekt und Cliquenbildung sind interessante Gedankengänge. Experience Programmer Clumping ist sehr verbreitet und hat enorme Auswirkungen. Viele IT-Manager sollten über diese Thematik noch mehr reflektieren als jetzt schon. Es stimmt, dass Eckel das schön auf den Punkt bringt aber Google hier noch keine Mio Treffer zu liefert. Das finde ich aber gut an diesem Artikel hier. Wenn ich mir beispielsweise den englischen Anti-Pattern Artikel anschaue so ist die punktuelle Einstreuung von solchen Anti-Pattern wie Programmer Experience Clumping eine fantastische, hoch-qualitative Abgrenzung. --Michael Hüttermann 19:51, 20. Mai 2006 (CEST)
replies: text:  deutsche Übersetzung irreführend.  Clumping eher im Sinne von Lebensgemeinschaften (Biologie): http://en.wikipedia.org/wiki/Clumping_(biology) ) Titel suggerierte, dass die Programmierer verklumpen. Es ist aber so, dass sich die Erfahrung verklumpt.--Michael Hüttermann 11:37, 4. Jun 2006 (CEST)
thread_title:  Programmer Experience Clumping 

message: Dieses Pattern scheint auch exklusiv auf bruce eckel's mindview.net vorzukommen. Gehört das hier hin? --Fasten 16:47, 19. Mai 2006 (CEST)
replies: text: Siehe auch Wikipedia:Relevanzkriterien - das Lemma sollte halt schon allgemein - zumindest innerhalb des Fachgebietes - bekannt sein. Als Informatiker kenne ich Patterns sehr wohl, ein Anti-Pattern ist mir aber noch nie unter gekommen. Aufgrund meiner persönlichen Erfahrung alleine würde ich es deswegen trotzdem nicht löschen lassen. Ggf. hilft ja auch die Flucht nach vorn - das Stellen eines Löschantrags. Dadurch werden viele Leute auf den Artikel aufmerksam und geben ihre Meinung ab. Entweder er überlebt oder er findet ein neues Leben eingebaut in anderen Artikeln zum Thema. --Manuel Schneider(bla) (+/-) 19:30, 19. Mai 2006 (CEST)
replies: text: Ich hoffe doch sehr, dass du nicht die Anti-Patterns an sich in Frage stellst? Die sind nun wirklich allgemein verbreitet. Diskutieren kann man natürlich über die Auswahl der Beispiele. --jpp ?! 20:12, 19. Mai 2006 (CEST)
replies: text: Ok, mein Fehler, ich habe diese Frage da etwas missverstanden. Zu diesem Beispiel will ich mich mangels Kenntnis nicht äussern. Gibts nicht ein anderes, welches bekannter ist? Wenn es wirklich nur dort vorkommt bin ich auch ein wenig unsicher, ob man das nehmen sollte. --Manuel Schneider(bla) (+/-) 20:31, 19. Mai 2006 (CEST)
replies: text: Anti-Pattern kommen aus der Praxis. Sie sind weit verbreitet, und gehören rund um die IT zur normalen Standard-Disziplin. Da ein riesiger Pool an Anti-Pattern existiert kann sich jeder gerne selbst einbringen hier in diesem Artikel die Anti-Pattern zu ergänzen, die ihm besonders wichtig und erwähnenswert erscheinen. Dieses konkrete Muster Faux System Architects wurde von Eckel unter diesem Namen eingeführt, gerade deswegen fügte ich auch die Quellenangabe hinzu. Ob dieser Name oder ein anderer: dieses Anti-Pattern ist extrem weit verbreitet, und gehört definitiv in den Artikel. Darüber hinaus möchte ich zu bedenken geben man solle doch nicht die Relevanz von Inhalten abhängig machen von google Suchergebnissen. Wir müssen uns hier auch inhaltlich gekonnt und qualifiziert abgrenzen. Ein einfaches Abschreiben von den besten google Ergebnissen macht noch keinen guten Artikel. In diesem von mir aufgesetzten Artikel fliessen immerhin 10 Jahre IT Erfahrung von mir persönlich ein. Und wenn denn mal ein hier angefügter Beitrag erst in der Zukunft zum Standard wird, dann können wir alle ganz Stolz sein. ;-) --Michael Hüttermann 15:02, 20. Mai 2006 (CEST)
replies: text:  Eigene Erfahrung einzubringen ist gut, aber ich würde z.B. protestieren wenn jemand anfängt eigene Anti-Pattern Namen zu erfinden die in der Literatur nirgendwo vorkommen und das damit begründet "das Pattern in der Praxis vorgefunden zu haben". Meine Frage ist also präzise: Ist eine einzelne Erwähnung bei Herr Eckel gut genug damit es in diesem Artikel erwähnt werden sollte? Wenn ja, warum? Gibt es vielleicht noch andere Namen für dieses Phänomen? --Fasten 19:17, 20. Mai 2006 (CEST)

text:  Sollten wir zu dem Konsens kommen, daß Patterns nicht einheitlich genug benannt werden und deswegen auch bei extrem seltener Nennung in der Literatur eine Erwähnung verdienen würde ich vorschlagen diesen Konsens im Kopf der Diskussionsseite zu verewigen. --Fasten 19:22, 20. Mai 2006 (CEST)
replies: text:  Hallo Fasten. Definitiv! Pesönliche Erfahrungen und Wissen...davon lebt die Wikipedia. Die Punkte und auch meine Argumente von Programmer Experience Clumping wiederholen sich an dieser Stelle. Auch dieses Pattern hier ist extrem verbreitet, und in der Literatur auch diskutiert. Schau mal in die Werke von Tom DeMarco. Ich habe noch keinen anderen, besseren Namen für diese geschilderte Entwicklung/Verhalten gefunden. Ich bin nicht dafür aus diesem Artikel einen Populär-Artikel zu machen, der sich an irgendwelche google Suchergebniszahlen orientiert. Ich habe bei der Erstellung ja absichtlich einen Fokus auf diese Art von Anti-Pattern gelegt, da diese viel größere Auswirkungen haben als irgendwelche Programmierungs-Anti-Pattern. Die Erfolge von IT-Projekten sind extrem abhängig von der Projekt-Soziologie, weniger von harten, technischen Faktoren. Diese zu erwähnen halte ich für sehr vernünftig. Jeder ist gerne eingeladen den Artikel zu erweitern, um weitere Anti-Pattern -in allen Kategorien- zu ergänzen. --Michael Hüttermann 20:05, 20. Mai 2006 (CEST)
replies: text:  Der Punkt ist, daß diese Entscheidung ein bewußter Verstoß gegen Wikipedia:Theoriefindung ist: "Ebenso unerwünscht sind Begriffsbildungen und Wortschöpfungen, das heißt, dass Begriffe, die in der Fachwelt nicht verbreitet sind, weder als Lemma noch in Artikeln verwendet werden dürfen." Der Grund für diese gewollte Verletzung einer Konvention wäre z.B. damit zu begründen, daß die Fachwelt Patterns nicht einheitlich benennt. Das sollte man dann aber (IMHO) auf dieser Talk Seite im Kopf auffinden können, damit dieser Punkt geklärt bleibt. --Fasten 20:09, 1. Jun 2006 (CEST)
replies: text:  Wir können das Thema gerne zentral oben für jeden Einzelfall separat abhandeln.  Aber bitte wirklich für den Einzelfall. Auf keinen Fall darf hier der ganze Artikel pauschalisiert werden. Es existiert ferner garkein Verstoss oder gar eine gewollte Verletzung einer Konvention, siehe meine Erläuterung oben.--Michael Hüttermann 14:58, 2. Jun 2006 (CEST)

text: Ich habe mir erlaubt den Text "Es existiert ferner eine grobe Relation zu dem bekannten Fischteicheffekt bzw. dem Assimilationseffekt. Siehe auch Neutraler Standpunkt. Aufführung in diesem Umfang ist also gerechtfertigt." aus den Anmerkungen zum Artikel zu streichen, weil Assimilationseffekts ein weiterer Link auf Fischteicheffekt war, Fischteicheffekt keinen starken Bezug zu diesem Pattern hat und der Verweis auf den neutralen Standpunkt so nicht verständlich ist. Ich bitte um eine klarere Formulierung wenn der Text wieder eingefügt werden soll. --Fasten 17:44, 3. Jun 2006 (CEST)
replies: text:  Der Hinweis auf Fischteicheffekt und Assimilationseffekts untermalt die Relevanz von dem von Dir kritisierten Anti-Pattern "Verklumpung erfahrener Programmierer". Ich habe mir erlaubt den Hinweis auf die Wikipedia Grundsätze zum "neutralen Standpunkt" aufzunehmen, da diese Grundsätze untermalen, dass dieses konkrete Anti-Pattern "Verklumpung erfahrener Programmierer" ausreichend relevant ist hier in diesem Artikel aufgeführt zu werden. Da Du auf die Grundsätze der Wikipedia Theoriefindung verwiesen hast scheint mir das legitim.--Michael Hüttermann 18:29, 3. Jun 2006 (CEST)
replies: text:  Auf Wikipedia Konventionen zu verweisen ist legitim aber nicht immer sinnvoll. Fischteicheffekt und Assimilationseffekt scheinen mir keinen unmittelbaren Bezug zur "Verklumpung erfahrener Programmierer" zu haben. Der Begriff stammt aus der Pädagogik, würde also höchstens für Schüler oder Informatikstudenten zutreffen, es sei denn man betrachtet eine Gruppe von Programmierern, aufgrund der Notwendigkeit ständigen Lernens in der heutigen Informatik, als Lerngruppe. Unter der Annahme, daß gerade in Firmen die „Management nach Zahlen“ betreiben Programmierer oft durch Austausch mit anderen Programmierern während der Arbeit lernen (ein Grund für IT-Berater) wären möglicherweise weder Assimilationseffekt noch Fischteicheffekt deutlich zu beobachten, weil "Verklumpung unerfahrener Programmierer" vor Ort die guten Lehrer aus der Gruppe entfernt  hätte, was aber nicht die primäre Ursache für diesen Effekt in der Pädagogik ist, da die Qualität und Anzahl der Lehrer nicht teil der Betrachtung ist. Umgekehrt könnte man auch behaupten, daß ein guter Programmierer in einer Gruppe weniger guter Programmierer eine stärkere Lernmotivation haben könnte, da seine oder ihre Leistungen dort besser auffallen; das würde der "Verklumpung erfahrener Programmierer" möglicherweise entgegenwirken. Außerdem könnte man den Fischteicheffekt auch als Gruppen/Cliquenbildung beliebiger Art (beispielsweise weltanschaulicher Art: Fisch) uminterpretieren, wie ich es bereits angeboten hatte, aber das ist natürlich durch die ursprüngliche Definition nichtmehr gerechtfertigt. Der Kommentar unter #Anmerkungen zum Artikel läßt leider offen welche Beziehung zwischen Fischteicheffekt und "Verklumpung erfahrener Programmierer" impliziert wird. --Fasten 15:44, 5. Jun 2006 (CEST)
replies: text:  Es freut mich dass Du meinen Verweis auf die Wikipedia Konventionen als legitim einstufst. Wie Dir sicherlich aufgefallen ist habe ich die suboptimale deutsche Übersetzung entfernt. Es geht hier eben nicht um eine "Verklumpung" von erfahrenen oder unerfahrenen Programmierern. Es geht hier um die Erfahrung selbst. Darüber hinaus verstehe ich immer noch nicht warum Du Deine Gedankengänge zu "Programmer Experience Clumping" unter "Faux System Architect" positionierst!? Also nachdem ich Dir ja sogar entgegen gekommen bin und den Hinweis oberhalb der Diskussion unterstützte sowie meinen Ausführungen zum Thema "Neutralität", "Minderheitenmeinung" und "Theoriedarstellung" und auch noch das von Dir eingeführte Beispiel "Fischteicheffekt" (möchtest Du den Fischteich-Artikel eigentlich löschen oder warum stehst Du dem so kritisch gegenüber?) mit in die Diskussion aufgenommen habe....was genau möchtest Du eigentlich? :-) --Michael Hüttermann 16:20, 5. Jun 2006 (CEST)

text:  Was ich möchte? Das hier . --Fasten 15:00, 8. Jun 2006 (CEST)

text:  Der Fischteicheffekt ist nicht identisch mit Programmer Experience Clumping. Der Fischteicheffekt ist eine mögliche Auswirkung einer Lerngruppe auf einen einzelnen Schüler während Programmer Experience Clumping ein Gruppierungseffekt bei Informatikern sein soll, der zur Bildung schwacher oder starker Gruppen führen könnte. --Fasten 15:00, 8. Jun 2006 (CEST)
replies: text:  zunächst mal vielen Dank für Deine Strukturierungen hier auf der Diskussionseite. Das sieht gleich viel übersichtlicher aus. Auch das Kästchen oben ist doch irgendwie ansprechender als dieses komplette ausgrauen. Inhaltlich: Ich möchte auch keine inhaltliche Abwägung zwischen PEC (ich nenn das mal so, immmer Programmer Experience Clumping schreiben ist ganz schön nervig) und Fischteicheffekt machen. Ich habe es nur aufgegriffen weil Du die Fischteiche in die Diskussion eingebracht hast. Wenn Fischteicheffekt als separater Artikel existiert, vielleicht sollten wir PEC auch zusätzlich ausführlich als separaten Artikel behandeln? Deine Idee ist sehr gut, sie gefällt mir.--Michael Hüttermann 23:28, 8. Jun 2006 (CEST)
thread_title:  Faux System Architects 

message: ::: Was ich möchte? Das hier . --Fasten 15:00, 8. Jun 2006 (CEST)
replies: text:  Der Fischteicheffekt ist nicht identisch mit Programmer Experience Clumping. Der Fischteicheffekt ist eine mögliche Auswirkung einer Lerngruppe auf einen einzelnen Schüler während Programmer Experience Clumping ein Gruppierungseffekt bei Informatikern sein soll, der zur Bildung schwacher oder starker Gruppen führen könnte. --Fasten 15:00, 8. Jun 2006 (CEST)
replies: text:  zunächst mal vielen Dank für Deine Strukturierungen hier auf der Diskussionseite. Das sieht gleich viel übersichtlicher aus. Auch das Kästchen oben ist doch irgendwie ansprechender als dieses komplette ausgrauen. Inhaltlich: Ich möchte auch keine inhaltliche Abwägung zwischen PEC (ich nenn das mal so, immmer Programmer Experience Clumping schreiben ist ganz schön nervig) und Fischteicheffekt machen. Ich habe es nur aufgegriffen weil Du die Fischteiche in die Diskussion eingebracht hast. Wenn Fischteicheffekt als separater Artikel existiert, vielleicht sollten wir PEC auch zusätzlich ausführlich als separaten Artikel behandeln? Deine Idee ist sehr gut, sie gefällt mir.--Michael Hüttermann 23:28, 8. Jun 2006 (CEST)
thread_title:  Fortsetzung der Diskussion über Programmer Experience Clumping, versehentlich unter Faux System Architects eingeordnet 

message: Ich habe noch das sehr gute Buch Die Psychologie des Programmierers. Seine Persönlichkeit, sein Team, sein Projekt. bei den Literaturhinweisen ergänzt. Ein sehr gutes Buches welches den Fokus auf soziologische, psychologische Aspekte hat welche sich in Anti-Pattern wie Programmer Experience Clumping und Faux System Architect wiederfinden.--Michael Hüttermann 20:15, 20. Mai 2006 (CEST)
thread_title:  Relevanz von soziologisch-orientierten Anti-Pattern 

message: Wie könnten geeignete Bilder aussehen, um den Artikel ein wenig visuell zu unterbauen? Mein double-checked locking Bild ist bisher das einzige Bild mit direktem Bezug welches darüber hinaus noch Zusatzinformationen bietet. --Michael Hüttermann 21:26, 20. Mai 2006 (CEST)
thread_title:  Bilder 

message: Anti-Pattern sind auch unter dem Begriff Negativmuster bekannt? Hast Du dazu eine Quelle? --Michael Hüttermann 22:16, 23. Mai 2006 (CEST)
thread_title:  Negativmuster 

message: In der Beschreibung des Anti-Patterns double-checked locking steht, dass das Schlüsselwort „volatile“ seit Java 5 eine neue Semantik hätte. Da ich das hier zum ersten Mal höre und in der entsprechenden Java-Dokumentation nichts dazu finden kann: Kann jemand eine Quelle dafür angeben? --jpp ?! 10:09, 31. Mai 2006 (CEST)
replies: text: http://www.jcp.org/en/jsr/detail?id=133 und darauf aufbauend zum Beispiel der sehr gute IBM-Links aus dem Artikel, welcher sich auch auf JSR 133 bezieht. --Michael Hüttermann 10:32, 31. Mai 2006 (CEST)
thread_title:  neue Semantik des Schlüsselworts „volatile“ in Java 

message: Hallo Leute. Ich würde von Euch gerne Feedback haben zu dem Artikel Anti-Pattern. Ich habe den Artikel vor geraumer Zeit neu erstellt und stetig fortgeschrieben. Der Artikel umfasst nun eine signifikante Erklärung zum Thema mit vielen Ausführungen und Beispielen. Ich freue mich sehr auf Euer konstruktives Feeback. Danke! --Michael Hüttermann 00:13, 7. Jun 2006 (CEST)
replies: text: Hi Michael, ich verstehe von dem Artikel nur Bahnhof, aber was ich Dir auf jeden Fall raten kann ist, die Spiegelstrich-Technik abzuschaffen und stattdessen einen zusammenhängenden Text schreiben. Kriegst du das hin? --Nina 00:34, 7. Jun 2006 (CEST)
replies: text:  Hi Nina. Danke für das flotte Feedback. :) Sorry, was meinst Du genau. Es existieren viele verschieden Anti-Pattern in unterschiedlichen Bereichen. Sie ein bisschen voneinander abtrennen fördert die Übersichtlichkeit. Oder? --Michael Hüttermann 00:53, 7. Jun 2006 (CEST)

text: Hallo Kurt. Vielen, vielen Dank für Dein Feedback! Mit den Wikilinks, das ist mir auch schon aufgefallen. Das pass ich an. Sorry, wie kann ich meinen Quelltext ("die Screenshots") als Code einfügen? Kannst Du mir da einen Tipp geben? Wie können wir ein Foto von Gamma oder anderen einbinden? Wie ist das da mit Copyright bestellt? Ich habe eine riesen Ladung an relevanter Literatur, aber das kann ich doch nicht einfach so hochladen oder?!? Ich mache es so wie Du sagst: ich verzichte auf die Überschriften und mach das mit Absätze. Das ist auf jeden Fall besser! Kursiv sind die Überschriften, wenn sie englisch sind, also den "Originaltext" haben. Das ist aber nicht "auf meinem Mist gewachsen". Ist das nicht OK so? Vielen Dank soweit, und ich hoffe Du findest noch Zeit mal weiter drüber zu lesen. Interessant ist es auf jeden Fall sehr, genauso wie der XP-Artikel. :-)--Michael Hüttermann 00:41, 9. Jun 2006 (CEST)
replies: text:  Wikilinks und Überschriften habe ich entfernt bzw. angepasst. Ach so, dass mit dem Leerzeichen war schon der Tipp mit dem Source Code. :-) Das find ich dann aber visuell auch nicht sooo ansprechend. Bliebe noch die Frage nach der Literatur, also Bilderchen von Gamma oder anderen einbinden. --Michael Hüttermann 12:14, 9. Jun 2006 (CEST)

text: danke für Dein Feedback! Einleitung: hier werde ich noch Hand anlegen. Hmmm, manche Abschnitte mögen subjektiv recht kurz wirken machen andererseits recht lang. Sowas resultiert immer aus einem eigenen Blickwinkel. Sprachliche Mängel: hmmm ich wüsste nicht wo, es wäre schön wenn da jemand hemdsärmlig aktiv werden könnte. Mir fallen da keine sprachlichen Mängel auf. Unverständlich? Ich werde "Programmer Experience Clumping" einen weitere persönlichen, genauen Review unterziehen bzgl. Verständlichkeit. Aber ich denke der Abschnitt sollte eigentlich verständlich sein, wobei er, ich gebe es zu, doch einen gewissen Startpunkt voraussetzt.--Michael Hüttermann 00:28, 12. Jun 2006 (CEST)
thread_title:  Diskussion aus dem Review vom 07.06.2006 bis zum 17.06.2006 

message: Wäre Not-Invented-Here-Syndrom nicht auch ein Kandidat für diese Seite? --SvenHerzberg 23:44, 18. Jun. 2007 (CEST)
thread_title:  Not-invented-Here 

message: Dies ist meines Erachtens absolut kein AntiPattern, sondern als Pattern korrekt. Bei dem beschriebenen Problem handelt es sich um ein Implementierungsproblem auf gewissen JVMs, bzw. die verwendung von ungeeigneten Variablen als Flags (nicht "volatile", > 32 Bit bzw. direktes Verändern des Wertes an der Referenz (Zwischenzustände u.u. sichtbar) vs. setzten der Referenz). Auf gewissen JVMs ist eine Verwendung dieses Patterns z.B. mit einem "volatile boolean" als Flag durchaus OK. 
Es handelts sich also nicht um ein Problem auf einer ganz anderen Ebene als auf der Entwurfsebene, auf der Patterns angesiedelt sind, und gilt keineswegs generell, sondern nur für Java und dort nicht immer (wobei es natürlich besser ist, es immer zu beachten).
Siehe auch: http://www.ibm.com/developerworks/java/library/j-dcl.html
: /signed. Das Double-Checked Locking als Anti-Pattern zu bezeichnen ist schlichtweg falsch. In C++ wird es in Verbindung mit dem Singleton Muster in einer Multithread-Umgebung sogar empfohlen. Ich verweise hier z.B. auf "Modernes C++ Design" von Andrei Alexandrescu Kapitel 6 "Singleton-Muster implementieren". 07.08.2007
Ich sehe es genauso. Das Double-Checked-Locking ist sogar in dem Buch "Effektiv Java Programmieren" (oder so ähnlich) als Verbesserung beschrieben gegenüber Locking der gesamten Methode mit synchronized, da das double Checked Locking schneller ist. Grüße, Christian
:Schneller mag es sein. Aber wechsle mal die Prozessorarchitektur oder die VM oder die Java-Version. Bumm! :-) Meinst du das Buch von Bloch oder das von Eßer? Welche Ausgabe? --j ?! 17:15, 23. Sep. 2008 (CEST)
replies: text:  Software Pattern stellen einen bereits oft verwendeten abstrakten Lösungsansatz für ein bestimmtes, weithin bekanntes Problem dar. (Ab hier eigene Meinung) In diesem Sinne gibt es nur für die jeweilige Situation schlecht gewählte, falsch angepasst oder falsch umgesetzte Entwurfsmuster. Entwurfsmuster sind nicht per se falsch/schlecht. Auch Singletons und Spaghetticode haben ihre Anwendungsfälle, diese sind jedoch - entgegen der Zahl Ihrer üblichen Verwendung - eher gering gehalten. Wird zudem auch noch begründet, dass das Entwurfsmuster ein Antipattern ist, weil es fehlerhaft implementiert wurde, fehlt jeder kausale Zusammenhang. Falsche Implementierungen sind lediglich Indikatoren für ein Entwurfsmuster, das leicht falsch umgesetzt wird.  --153.96.12.26 09:48, 11. Mär. 2016 (CET)

text: Und wie stellst du sicher, dass "später" auch wirklich später ist? Du hast hier effektiv wieder das selbe Problem. Die Prüfung "Ressource ist geladen" kann true liefern, obwohl die Ressource noch nicht vollständig geladen ist. --Der Hâkawâti ✉ 09:06, 13. Jan. 2010 (CET)
replies: text:  Ich lesen das Beispiel folgendermaßen: Das Laden der Resource wird angestoßen und asynchron durchgeführt. Der eigentliche Programmfluss wird weitergeführt und spaltet sich in optional mehrere parallel ablaufende Anteile auf. Diese Parallel ablaufenden Programmflüsse greifen dann nachgelagert auf die Resource zu, die dann zwingend geladen sein muss. Double-Checked-Locking sollte man dann einem normalen Lock vorziehen, wenn der Zugriff häufig passiert und die Verwendung eines Locks zu viele Performanceeinbußen mit sich bringen würde. --153.96.12.26 09:48, 11. Mär. 2016 (CET)
thread_title:  Double-Checked Locking 

message: In diesem Abschnitt ist von "Sophomore" die Rede. Es geht doch hier um einen "Semaphor", nicht wahr?
:Nein. Aber da das oft falsch verstanden wurde, habe ich den Abschnitt umformuliert. --jpp ?! 16:43, 20. Aug. 2007 (CEST)
thread_title:  Sophomore 

message: 'Dead body' ist durchaus ein Begriff für 'Leiche' ("over my dead body"). 
In diesem Fall ist es aber keine, denn ein 'warm body' ist einfach ein 'warmer Körper'.
Das ist auch die eigentliche Metapher: dieser Mensch ist nur ein warmer Körper.
--mikl 17:47, 23. Dez. 2007 (CET)
replies: text:  Meiner Meinung nach ist 'Warme Leiche' die korrekte Übersetzung. Wärme erweckt den Anschein von Leben, tatsächlich ist die Person aber nicht produktiv, also sozusagen tot (vgl. 'totes Kapital'). Trilemma2 23:01, 6. Okt. 2011 (CEST)
replies: text: 'body' an sich kann bereits 'Leiche' bedeuten, was in diesem Kontext auch Sinn ergibt.  217.76.104.98 16:27, 30. Jul. 2014 (CEST)
thread_title:  Warm body - wo ist da die Leiche? 

message: Hallo
Ich habe versucht, die Einleitung etwas verständlicher zu formulieren. Beim folgenden Satz bin ich an meine Grenzen gestossen, weil ich schlichtweg nicht verstehe, was er sagen will:
 Zu beobachten ist allerdings auch die bewusste Verfolgung in bestimmten Szenarien, um einen bestimmten Zweck zu erreichen.
Ausserdem schlage ich vor, das Lemma "Antimuster" zu verwenden, da es deutsch ist und durchaus viele Google-Treffer bringt auch auf microsoft.com etc., und auch so in Entwurfsmuster erwähnt wird. Das würde bedeuten:
* Anti-Pattern nach Antimuster verschieben
* Alle "Anti-Pattern" im Artikel durch "Antimuster" ersetzen.
* In der Einleitung: "Antimuster (englisch: Anti-Pattern) bezeichnet..." statt umgekehrt.
Gruss, --Chiccodoro 18:58, 18. Mär. 2008 (CET)
thread_title:  Verständlichkeit; Lemma 

message: Man beachte  (ein nützlicher Beitrag) und den folgenden kleinen Edit-War, nach dem die Diva nun doch keinen Platz im Artikel gefunden hat, mangels Quellennachweis. --Mopskatze℅Miau! 14:08, 9. Aug. 2008 (CEST)
replies: text: Die Frage, um die es dabei geht, ist ob der Begriff in der Literatur verbreitet ist oder ob es sich um Wikipedia:Theoriefindung handelt, also einen Begriff, den sich Anonymus selbst ausgedacht hat. Sobald jemand einen brauchbaren Beleg anführt, darf die Diva gerne wieder rein in den Artikel. --j ?! 21:24, 9. Aug. 2008 (CEST)
thread_title:  Diva 

message: Die Anmerkung von Programmieren als "künstlerischer" Prozess, ist für mich nicht nachvollziehbar. Da es hier um die Entwicklung eines Systems geht, halte ich die Referenz auf "Programmieren als Kunst" für unglücklich gewählt. Wie bei der Entwicklung anderer Systeme auch ist es eine Tätigkeit die mehr ingenieurmäßig (systematisch, diszipliniert und messbar) ausgeübt wird. Es bleibt, da etwas neues entsteht, ein kreativer, schöpferischer Akt, aber eben nicht ein künstlerischer Akt. Software-Engineering zählt eben nicht zu den Künsten.
:Es sind dies die Worte von Personenkreisen, die vorgeben Ahnung zu haben und doch nie eine Zeile selbst programmiert haben. Programmieren ist keine künstlerische Tätigkeit, bei denen ein Kunstwerk in Form eine Bildes oder eine Skulptur herauskommt - Programmieren entzieht sich sehr oft leider auch der Messbarkeit. Auch ich betreue im Moment ein Projekt, das sich bei der Function-Point-Zählung massiv verschätzt hat - und das ohne Absicht oder Dummheit. Diejenigen, die es dann schaffen unter unmöglichen Rahmenbedingungen dennoch etwas auf die Beine zu stellen, die sind sehr wohl Künstler. ein Beispiel gefällig: Eine Software für ein embeddes System wurde entwickelt, die Speuzifikation erstellt und die Sache implementiert. Bis dahin war es ingenieursmässige Arbeit. Der Code hatte rund 12MB, auf dem ES standen jedoch nur 1 MB zur Verfügung. Der Künstler hat es geschaft die volle Funktionalität auf ein MB zusammenzustauchen ohen Abstriche in der Funktionalität zu machen. Ich möchte sehen wo du dies misst oder wie du das planst! 84.170.78.109 18:05, 10. Aug. 2010 (CEST)
replies: text: Diese Diskussion ist doch wohl nicht ernst gemeint! Und wenn doch: es ist völlig ausgeschlossen, dass Programmieren in einer Enzyklopädie als künstlerischer Prozess beschrieben wird. Nebenbei gesagt kommen solche kleinen "Wunder" auch in anderen technischen Bereichen vor, da wird dann vielleicht die eine oder andere poetisch sagen, es sei ein Kunstwerk, das tut aber nichts zur Sache. --Michael Scheffenacker 18:35, 28. Dez. 2011 (CET)
thread_title:  Management nach Zahlen 

message: Es mag stimmen, daß unter dem Namen "Anti-Pattern" so allerlei Ideen kursieren. Einiges davon hat in der Tat Substanz, anderes ist aus einer verengten Perspektive heraus gedeutet. Ich bin vom Fach und weise Erfahrungen sowohl in der Welt des Managements als auch in der Welt des Programmierens auf. Ich kann mit Sicherheit sagen, daß ein signifikanter Teil der Patterns so gut wie unbekannt ist bzw. höchstens soviel Akzeptanz findet wie die Aussage daß CocaCola fit und gesund macht. Die vielen Superlative in der Diskussionsseite: "breite Öffentlichkeit", "weite Kreise der Fachwelt" usw. usw. sprechen da Bände - es soll kaschiert werden, daß das Gegenteil der Fall ist (Hinweis: eine breite Öffentlichkeit besteht nicht aus ein paar Programmierer-Kumpeln im gleichen Büro).
Wie dem auch sei, Meinungen kann und darf es viele geben. Was dem Artikel fehlt ist der Nachweis, welche Patterns im einzelnen woher kommen, und welche Akzeptanz sie aufweisen. Ich bin überzeugt, daß dieser Nachweis eben auch gar nicht führbar ist, da es diese allgemein Akzeptanz gar nicht gibt.
Ich kann leider unter keiner der unten genannten Referenzen eine finden, auf der sich in der Breite der Nachweis führen ließe, daß alle die aufgelisteten Pattern allgemein akzeptiert sind. Welcher oder welche der Links sollen das belegen?
Um das zu präzisieren: die Fachwelt für die Verwendung von "volatile" mag noch aus der Welt der Entwickler bestehen, obwohl sich selbst dort die Frage stellt, wer da die breite Öffentlichkeit im Detail ist, die das Pattern exkommuniziert hat, spätestens bei Fragen der Projektdurchführung bzw. des Managements umfaßt diese Fachwelt jedoch einen weit größeren Personenkreis, in dem von Anti-Patterns nicht im entferntesten geredet wird. Selbsternannte Management-Experten aus der Software-Welt machen keine breite Öffentlichkeit aus.
So sehr ich persönlich das Portland Pattern Repository teilweise auch schätze, kommt es als Beleg - zu recht - nicht in Frage: Wikipedia:Belege#Was_sind_zuverl.C3.A4ssige_Informationsquellen.3F, 4. Abschnitt ("Nach dem Wiki-Prinzip...").
Insgesamt ist gegen die Auflistung auf dieser Wikipedia Seite nicht unbedingt etwas zu sagen, es sollte nur in der Einleitung klar und deutlich gesagt werden, daß die Patterns eine schlichte Aufsammlung darstellen, mit einigen solide verifizierten Exemplaren, und einigen recht umstrittenen bwz. unbekannten. (nicht signierter Beitrag von 80.171.108.104 (Diskussion | Beiträge) 26. Juni 2009, 10:45 Uhr) 
:Vollkommen unverständlich, warum der Kommentator in dieser abstrakten, auch persönlichen Art und Weise den Autor angeht, anstelle einfach selbst konstruktiv mit anzufassen, und die Energie und Zeit sinnvoll zu nutzen. Gebe es einen Artikel über Antimuster bei Wikipedia-Diskussionen, dieser Kommentar müsste zwingend aufgenommen werden. Eine umfangreiche Gruppe von Antimustern als "nicht fundiert genug" zu pauschalisieren, ist wenig zielführend. Welcher Eintrag genau ist denn nicht zielführend? Alle Einträge sind praxisrelevant und können von jedem halbwegs erfahrenen IT-Experten so unterschrieben werden. --84.135.117.114 (20:37, 9. Jun. 2011 (CEST)
thread_title:  Die Welt gedeutet aus der Sicht eines Entwicklers 

message: Nur eine kleinigkeit: es sind (n^2-n)/2 KommunikationsPARTNER, nicht KommunikationsPAARE. Bitte noch korrigieren.
-- Georg (01:33, 2. Aug. 2009 (CEST)
replies: text: Hi. Danke für den Hinweis. Aber wer oder was hindert dich daran, es selbst zu korrigieren? --j ?! 19:00, 5. Aug. 2009 (CEST)
thread_title:  Brooksches Gesetz 

message: Sind diese irgendwo belegt?
* "Außerirdische Spinnen" (sogar noch (subjektiv) kommentiert mit "Ein Entwurf, welcher die Bezeichnung als einen solchen nicht verdient."): "Alien" heißt nur zweitrangig "Ausserirdisch". Kern ist "fremd" (was dann auch garnicht mehr so unverdient wirkt.
* "Erdölraffenerie": "Gas" heißt auch "Abgas", womöglich sogar mit Anspielung auf bestimmte menschliche Gase. Ein System, das nur "heiße Luft" produziert "Gas Factory" zu nennen, wirkt schlüssiger (nicht signierter Beitrag von 91.66.67.136 (Diskussion) 16:18, 10. Feb. 2012 (CET)
replies: text: Also ich finde bei Google weder etwas von Erdölraffinerien noch Laber-Fabriken im Kontext von Design-Patterns. Wo hast du die Übersetzung her? Sollte man womöglich einfach unübersetzt lassen, da es sich sonst um Begriffsfindung handelt. Was ist am Abschnitt zu Alien Spiders subjektiv? Der Satz bezieht sich auf die Bezeichnung als Entwurf, nicht auf die Bezeichnung als „außerirdische Spinne“. --Chricho ¹ ² 14:14, 24. Mär. 2012 (CET)
replies: text:  Ich denke auch, dass nicht-etablierte Übersetzungen zumindest nicht als Hauptbegriff verwendet werden sollten. Eine ungefähre Übersetzung ("engl. etwa ...") sollte bei englischen (= fremdsprachigen!) Begriffen dann aber meiner Meinung nach doch sein. Wie man jetzt konkret die Gas Factory übersetzen will ... schwierig. Das ist nicht der übliche Begriff für Erdölraffinerien, deshalb halte ich die Übersetzung auch nicht für gelungen (obwohl ja so eine Raffinerie etwas irrsinnig Komplexes ist). Eine "Laber-Fabrik" ist es aber auch nicht, hier wird ja nicht gelabert, hier wird Code geschrieben. --YMS (Diskussion) 15:44, 4. Apr. 2012 (CEST)
thread_title:  Deutsche Übersetzungen 

message: Eigentlich besser bekannt als Management bei Helikopter: Einfliegen, Schmutz aufwirbeln, und wieder Ausfliegen.
Quellen: Diverse - siehe z.B. Google. (nicht signierter Beitrag von 87.253.189.125 (Diskussion) 09:16, 24. Mai 2012 (CEST)
thread_title:  Crocodile Management 

message: Habe ich noch nie gehört. Deutschsprachige Bezeichnungen sind zwar zu bevorzugen, aber nicht um jeden Preis. Wer benutzt das bitte? --Chricho ¹ ² ³ 23:39, 31. Jan. 2013 (CET)
replies: text: Nicht nur das Lemma ist unangemessen. Begriffe wie "Außerirdische Spinnen" und "Matschklumpen" gibt es gar nicht im SE. Sollten wir ändern. ʘχ (Diskussion) 23:08, 21. Feb. 2013 (CET)
thread_title:  Antimuster 

message: Wenn mich meine Erinnerung nicht trügt, hat mal einer (Lambsdorff?) im Bundestag über die Personalpolitik der CSU gesagt:
"Sie machen es wie andere Pilze züchten: Immer schön im Dunkeln, immer fleißig Mist drauf, und wenn doch einer den Kopf rausstreckt, wird er sofort abgeschnitten."
Das muss so um 1990 rum gewesen sein. (nicht signierter Beitrag von 193.138.10.34 (Diskussion) 14:54, 7. Mai 2014 (CEST)
thread_title:  Pilze gibt's schon länger 

message: Der Artikel definiert die "englische Theorie" als die der Ausbeutung vorhandener Werte und die "spanische Theorie" als die der kreativen Erzeugung von Werten. 
In meiner Erinnerung ist das anders herum. Die Spanier haben Mittelamerika geplündert während England zur Industrienation aufstieg.
Leider habe ich bei meiner Suche nur im DeMarco / "Wien wartet auf Dich" eine Referenz gefunden. Er schreibt: "Nach der spanischen Theorie beispielsweise existiert nur eine feste Menge von Werten auf der Welt. Deshalb liegt der Weg, Reichtümer anzuhäufen, in der Erkenntnis, wie man diese effizienter aus dem Boden und aus dem Rücken der Leute herausholt. Alternativ dazu gab es die englische Theorie, nach der man Werte duch Genialität und Technologie schaffen kann." (nicht signierter Beitrag von 80.146.181.100 (Diskussion) 08:39, 16. Mai 2014 (CEST)
replies: text: Ja, hab den Abschnitt mal entfernt. Tatsächlich findet man den Begriff "Spanish Theory Management" ausschließlich bei DeMarco (auch in "Peopleware: Productive Projects and Teams"). Und wie bereits geschrieben, wird es dort genau anders herum beschrieben. Außerdem geht es am Thema des Abschnitts "Management nach Zahlen" vorbei, bzw. hat recht wenig damit zu tun... --80.149.210.186 09:03, 18. Jan. 2019 (CET)
thread_title:  spanische und englische Theorie des Managements