Diskussion:Anti-Pattern

Anmerkungen zum Artikel

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) --Michael Hüttermann 14:47, 2. Jun 2006 (CEST)

1. „Verklumpung erfahrener Programmierer“: stellt ein sehr wichtiges, enorm verbreitetes Anti-Pattern dar. Es wird zwar in der Fachwelt hinreichend diskutiert, allerdings nicht unter einem einheitlichen Begriff. Der für den Artikel gewählte Begriff kommt von Eckel, siehe Verlinkung. Dessen konkrete Benutzung unter diesem Begriff ist darüber hinaus auch mindestens eine Minderheitenmeinung, welche ebenfalls als historisch zu bezeichnen ist und definitiv zu einer breiten, öffentlichen Diskussion geführt hat.

Großschreibung des Lemmas

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)

ok, überredet. :-) danke, dass Du das schon angepasst hast. --Michael Hüttermann 14:10, 9. Mai 2006 (CEST)

Lavafluss

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)

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)

Programmer Experience Clumping

Der Text ähnelt [1]. 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)

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)

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)

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)

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)

Faux System Architects

Dieses Pattern scheint auch exklusiv auf bruce eckel's mindview.net vorzukommen. Gehört das hier hin? --Fasten 16:47, 19. Mai 2006 (CEST)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Fortsetzung der Diskussion über Programmer Experience Clumping, versehentlich unter Faux System Architects eingeordnet

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

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)

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)

Relevanz von soziologisch-orientierten Anti-Pattern

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)

Bilder

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)

Negativmuster

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

neue Semantik des Schlüsselworts „volatile“ in Java

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)

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)

Diskussion aus dem Review vom 07.06.2006 bis zum 17.06.2006

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)

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)

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)

Hallo Michael, ein paar Formsachen:

• bitte keine Wikilinks in Überschriften
• die Eclipse-Screenshots bitte als code einfügen (mit einem Space einrücken), damit die Sache leichter lesbar wird. Lieber keine Bilder als Textfotos. Schön wärs, wenn wir Fotos von Gamma o.ä. auftreiben könnten.
• Überschriften mit nur einer Zeile Text sind hässlich. Stichpunkte leider auch. Zum Teil könnte man einfach mehr zu den einzelnen Punkten schreiben. Mein Vorschlag wäre, auf die (unterste Ebene der) Überschriften komplett zu verzichten und einfach Absätze zu machen, in denen die Anti-Patterns kursiv hervorgehoben sind. Übrigens sind einige Überschriften kursiv, andere nicht.

Leider hab ich den Artikel heute nur überflogen. In den nächsten Tagen werde ich ihn komplett lesen und wahrscheinlich hier nochmal was sagen. Sieht aber sehr interessant aus. Den XP-Artikel schaff ich hoffentlich auch noch. :-) --Kurt seebauer 00:24, 8. Jun 2006 (CEST)

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)

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)

Hallo Michael, ein paar weitere Punkte:

• in der Einleitung werden die Anti-Patterns den aus der Softwaretechnik bekannten Design-Pattern gegenübergestellt. Diese gegenüberstellung passt aber IMO nicht ganz, weil es bei den Anti-Patterns nicht nur um Softwaretechnik geht, sondern auch um andere Bereiche.
• teilweise sind die einzelnen Abschnitte recht kurz. Man könnte (Code-)Beispiele bringen. Bei manchen Punkten würde sich sicherlich auch ein eigener Artikel lohnen.
• teilweise sprachliche Mängel, z.B. keine ganzen Sätze.
• zum Teil etwas unverständlich, z.B. der Abschnitt "Programmer Experience Clumping".

--Kurt seebauer 20:16, 11. Jun 2006 (CEST)

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)

Gasfabrik?

Wenn es im Englischen "gas factory" heißt, vermute ich, daß damit keine "Gasfabrik" gemeint ist, sondern eher eine "Benzinfabrik" (gasoline = Benzin!), also eine Raffinerie. Es soll ja um etwas besonders kompliziertes gehen, da drängt sich eine Raffinerie doch auf, oder? Mfgkw 14:32, 29. Sep 2006 (CEST)

Wenn man Google nach "gas factory" fragt (leo und m-w kennen es nicht), bekommt man neben reichlich Links zu Herstellungsorten gasförmiger Produkte (Sauerstoff, Nerven- oder Giftgas, ...) einen Link auf das absurde Patent zum Herausfiltern der Methan-Ausdünstungen von Wiederkäuern. ;-)

Laut dem Artikel en:Gas factory ist damit definitiv eine Erdölraffinerie gemeint. --Phst 15:06, 23. Jun. 2008 (CEST)

Absoluter Schwachsinn! Was sollte die Übersetzung "Erdölraffinerie" in dem Zusammenhang für einen auch nur ansatzweise erkennbaren Sinn machen? "to gas" heißt umgs. labern. Eine gas factory ist ein Produzent von Geschwafel. --94.220.231.197 12:36, 24. Mär. 2012 (CET)

Vom umgs. labern her kommt mir als deutschsprachige Analogie "heisse Luft" in den Sinn. So könnte z. B. "to gas" mit "redet nur heisse Luft" "heisse Luft produzieren" oder so übersetzt werden. Für die "gas factory" kommen mir mögliche Übersetzungen wie "Heissluftbalon" "Heisse Luft Fabrik" "Sauna" "Luftbefeuchter" in den Sinn. Wie nennt ihr sowas umgs. auch noch? --84.20.36.138 11:18, 16. Apr. 2012 (CEST)

Not-invented-Here

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

Double-Checked Locking

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 (nicht signierter Beitrag von 143.164.102.13 (Diskussion) )

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) PS: Bitte unterschreib deine Beiträge immer mit „--~~~~“

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)

Noch ein Hinweis: Wer sagt, dass man immer ein Objekt zurückgeben möchte. Möchte man beispielsweise das Laden einer Ressource sicherstellen (um z.B. die spätere Ladezeit zu verkürzen), jedoch an dieser Stelle noch nicht unmittelbar darauf zugreifen, so gibt es erst recht kein Problem mit etwaigen Objekten, die sich in der Initialisierung befinden. Beim nur schreibenden Zugriff kann man Double-Checked-Locking verwenden, beim lesenden Zugriff womöglich das normale Locking. --Chricho 01:34, 13. Jan. 2010 (CET)

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)

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)

Sophomore

In diesem Abschnitt ist von "Sophomore" die Rede. Es geht doch hier um einen "Semaphor", nicht wahr? (nicht signierter Beitrag von 212.90.206.43 (Diskussion) )

Nein. Aber da das oft falsch verstanden wurde, habe ich den Abschnitt umformuliert. --jpp ?! 16:43, 20. Aug. 2007 (CEST) PS: Bitte unterschreibe deine Diskussionsbeiträge immer mit vier Tilden.

Warm body - wo ist da die Leiche?

'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)

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)

'body' an sich kann bereits 'Leiche' bedeuten, was in diesem Kontext auch Sinn ergibt. [3] 217.76.104.98 16:27, 30. Jul. 2014 (CEST)

Verständlichkeit; Lemma

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)

http://www.theserverside.de/singleton-pattern-in-java/ erklärte den Sachverhalt falsch, deswegen gelöscht

Ich habe den Autor mehrfach per E-Mail darauf hingewiesen, er hat aber nur marginale Zeilennummernfehler berichtigt. Da er seit meiner letzten E-Mail trotz anderslautendem Bekenntnis nicht mehr reagiert hat habe ich diesen sachlich falschen Link gelöscht.

Anbei mein E-Mail Verkehr mit dem Autor obigen Artikels (E-Mail Adressen anonymisiert):

 Von: 	xxx@xxx.com
 Betreff: 	AW: AW: Singleton Pattern in Java
 Datum: 	3. Februar 2008 20:23:55 MEZ
 An: 	xxx@xxx.com
 
 Sorry für die noch nicht erfolgte Rückmeldung. Ich schaue mir das in den nächsten Tagen noch einmal in Ruhe an und melde mich zurück.
 Bis dahin wünsche ich eine erfolgreiche Woche!
 
 Viele Grüße,
 Rias
 
 
 -----Ursprüngliche Nachricht-----
 Von: Lars Sonchocky-Helldorf [4] 
 Gesendet: Dienstag, 29. Januar 2008 12:11
 An: Rias A. Sherzad
 Betreff: Re: AW: Singleton Pattern in Java
 
 
 Am 28.01.2008 um 19:28 schrieb Rias A. Sherzad:
 
 > Hallo Herr Sonchocky-Helldorf,
 > 
 > vielen Dank für Ihre Nachricht.
 > 
 > Wenn ich Ihren Hinweis richtig verstanden habe, dann habe ich mich  
 > bei der
 > Zählung der Zeilennummern im Artikel vertan - da stehen überall noch
 > Kommentare drin, die ich nicht richtig mitgezählt habe. Ich habe die
 > Korrekturen vorgenommen und denke, das das jetzt alles wieder stimmen
 > müsste.
 
 Meine Einwände bestehen weiterhin. Ich versuche es am konkreten  
 Beispiel zu erklären:
 
    1.
       package de.theserverside.designpatterns.singleton;
    2.
 
    3.
       /**
    4.
       * Implementierung des Singleton-Patterns mit synchronisiertem
    5.
       * Zugriff auf die Instanziierung und zweifacher Bedingungsprüfung
    6.
       */
    7.
       public class DoubleCheckedLockingSingleton {
    8.
           private static DoubleCheckedLockingSingleton instance = null;
    9.
 
   10.
           /**
   11.
            * Default-Konstruktor, der nicht außerhalb dieser Klasse
   12.
            * aufgerufen werden kann
   13.
            */
   14.
           private DoubleCheckedLockingSingleton() {}
   15.
 
   16.
           /**
   17.
            * Statische Methode, liefert die einzige Instanz dieser
   18.
            * Klasse zurück
   19.
            */
   20.
           public static DoubleCheckedLockingSingleton getInstance() {
   21.
               if (instance == null)  
 {                                                                        
 //      <-- Dieser Ausdruck evaluiert zu false, wenn assignMemory 
 (instance, ptrMemory) bereits ausgeführt wurde -> Thread 2 läuft  
 nicht auf das Lock
   22.
                   synchronized(DoubleCheckedLockingSingleton.class) {
   23.
                       if (instance == null) {
   24.
                           instance = new  
 DoubleCheckedLockingSingleton();
   25.
                       }
   26.
                   }
   27.
               }
   28.
               return  
 instance;                                                                
               //      <--  sondern liefert instance zurück bevor  
 callDoubleCheckedLockingSingletonConstructor(instance) aufgerufen wurde
   29.
           }
   30.
       }
 
 > Das könnte doch funktionieren... wäre da nicht das Speichermodell  
 > der Java-Plattform! Die zweite Bedingung if (instance == null) in  
 > Zeile 23 kann nämlich zu true evaluieren, ohne daß new  
 > DoubleCheckedLockingSingleton() aufgerufen, und das instanziierte  
 > Objekt dem Klassenattribut instance zugewiesen wurde!
 
 
 Das ist ja auch richtig so. So lange instance nichts zugewiesen  
 wurde, ist es null :-), der zweite Thread käme ohnehin nicht bis an  
 die zweite if (instance == null) Abfrage, da er am Lock warten muss  
 sobald er die erste if (instance == null) Abfrage überwunden hat. Da  
 er am Lock erst vorbeikommt, wenn der erste Thread das Lock  
 zurückgibt, besteht hier keine Gefahr, dass die Initialisierung von  
 instance ein zweites mal durchlaufen wird. Das Problem ist also  
 tatsächlich nicht die zweite if (instance == null) Abfrage sondern  
 die erste. Sobald ein zweiter Thread an dieser ersten Prüfung  
 "vorbeikommt" und nicht auf das Lock aufläuft, wie die eigentliche  
 Intention hier ist (eben weil instance bereits Speicher zugewiesen  
 bekommen hat und damit nicht mehr null ist) kann dieser zweite Thread  
 instance zurückgeben, bevor das Lock des ersten Threads gelöst worden  
 und damit instance vollständig initialisiert worden ist.
 
 Ich muss zugeben, dass ich in der Vergangenheit selbst  
 DoubleCheckedLockingSingletons verwendet habe, allerdings in der in  
 http://www.ibm.com/developerworks/library/j-dcl.html beschriebenen  
 Form mit einer lokalen Hilfsvariable, welche ich für sicher hielt:
 
 public static Singleton getInstance()
 {
   if (instance == null)
   {
     synchronized(Singleton.class) {      //1
       Singleton inst = instance;         //2
       if (inst == null)
       {
         synchronized(Singleton.class) {  //3
           inst = new Singleton();        //4
         }
         instance = inst;                 //5
       }
     }
   }
   return instance;
 }
 
 
 mir war dabei nicht bewusst, dass der JIT hier optimierend eingreift:
 
 
 
 public static Singleton getInstance()
 {
   if (instance == null)
   {
     synchronized(Singleton.class) {      //1
       Singleton inst = instance;         //2
       if (inst == null)
       {
         synchronized(Singleton.class) {  //3
           //inst = new Singleton();      //4
           instance = new Singleton();
         }
         //instance = inst;               //5
       }
     }
   }
   return instance;
 }
 
 und somt das ganze auch nicht 100% sicher ist.
 
 aber man lernt ja nie aus … :-)
 
 
 > Um das exemplarisch zu verdeutlichen, schauen wir uns den folgenden  
 > Pseudo-Bytecode für den Befehl instance = new  
 > DoubleCheckedLockingSingleton() an:
 > 
 >   1.
 >      // Speicher alloziieren
 >   2.
 >      ptrMemory = allocateMemory()
 >   3.
 >      // Den Speicher dem Klassenattribut zuweisen, ab hier gilt:  
 > instance != null
 >   4.
 >      assignMemory(instance, ptrMemory)
 >   5.
 >      // Den Konstruktor aufrufen, das Objekt ist dann ab hier  
 > korrekt instanziiert
 >   6.
 >      callDoubleCheckedLockingSingletonConstructor(instance)
 > 
 > Zwischen der zweiten und der vierten Zeile könnte die Ausführung  
 > des Threads durch die Java Virtual Machine unterbrochen, und die  
 > Ausführung eines zweiten Threads vorgezogen werden. Die zweite  
 > Bedingung if (instance == null) würde damit zu true evaluieren,  
 > ohne daß bisher der Konstruktor (Zeile 6)
 
 Hier hab ich noch einen kleinen Zeilennummernfehler entdeckt. Gemeint  
 ist wohl Zeile 24.
 
 > aufgerufen worden wäre. Das double-checked locking ist damit nicht  
 > sicher.
 > Konstrukte wie diese sind in JIT-Compilern nicht unüblich und da  
 > man nicht immer voraussagen kann, wo der Code läuft sollte man das  
 > double-checked locking vermeiden, um auf der sicheren Seite zu stehen.
 > 
 > 
 > Vielen Dank & viele Grüße,
 > Rias A. Sherzad
 
 
 Viele Grüße,
 
   Lars
 
 
 > 
 > 
 > -----Ursprüngliche Nachricht-----
 > Von: Lars Sonchocky-Helldorf [mailto:xxx 
 > @xxx.com]
 > Gesendet: Montag, 28. Januar 2008 16:34
 > An: xxx@xxx.com
 > Betreff: Singleton Pattern in Java
 > 
 > Bezugnehmend auf Ihren Artikel:
 > 
 > <http://www.theserverside.de/singleton-pattern-in-java/>
 > 
 > Schön erklärt, aber leider hier falsch:
 > 
 > > Das könnte doch funktionieren... wäre da nicht das Speichermodell
 > > der Java-Plattform! Die zweite Bedingung if (instance == null) in
 > > Zeile 7 kann nämlich zu true evaluieren, ohne daß new
 > > DoubleCheckedLockingSingleton() aufgerufen, und das instanziierte
 > > Objekt dem Klassenattribut instance zugewiesen wurde! Um das
 > > exemplarisch zu verdeutlichen, schauen wir uns den folgenden Pseudo-
 > > Bytecode für den Befehl instance = new DoubleCheckedLockingSingleton
 > > () an:
 > > 
 > >   1.
 > >      // Speicher alloziieren
 > >   2.
 > >      ptrMemory = allocateMemory()
 > >   3.
 > >      // Den Speicher dem Klassenattribut zuweisen, ab hier gilt:
 > > instance != null
 > >   4.
 > >      assignMemory(instance, ptrMemory)
 > >   5.
 > >      // Den Konstruktor aufrufen, das Objekt ist dann ab hier
 > > korrekt instanziiert
 > >   6.
 > >      callDoubleCheckedLockingSingletonConstructor(instance)
 > > 
 > > Zwischen der zweiten und dritten Zeile könnte die Ausführung des
 > > Threads durch die Java Virtual Machine unterbrochen, und die
 > > Ausführung eines zweiten Threads vorgezogen werden. Die zweite
 > > Bedingung if (instance == null) würde damit zu true evaluieren,
 > > ohne daß bisher der Konstruktor (Zeile 3) aufgerufen worden wäre.
 > 
 > 
 > 
 > Es ist genau anders herum. Für instance wurde bereits Speicher
 > alloziert, ist dadurch nicht mehr null und damit evaluiert der
 > *erste* Test (Zeile 21) if (instance == null) zu false, der
 > betroffene Thread läuft am Lock vorbei und die Methode gibt eine
 > nicht initialisierte instance zurück. Der zweite Thread hätte nämlich
 > gar keine Chance, an die zweite Bedingung zu gelangen, bevor das Lock
 > zurückgegeben wurde. Die zweite Bedingung ist nur dazu da, die am
 > Lock wartenden Threads *nach* der (vollständigen) Initialisierung von
 > einer wiederholten Ausführung der Initialisierung abzuhalten.
 > 
 > Und eine Kleinigkeit noch: Sie meinen in ihrem Text nicht Zeile 7
 > sondern Zeile 23.
 > 
 > 
 > Bitte berichtigen Sie ihren Artikel (offenbar ist das ganze den
 > anderen Lesern nicht aufgefallen und verwirrt diese).
 > 
 > Siehe auch http://www.ibm.com/developerworks/library/j-dcl.html
 > Absatz Out-of-order writes
 > 
 > 
 > MfG,
 > 
 >   Lars S.-Helldorf

Hallo Ihr beiden, ist zwar hochinteressant, aber gehoehrt wohl eher zu Parallelisierung, oder JVM.

Ausserdem scheint mir http://www.theserverside.de/singleton-pattern-in-java/ tatsaechlich nicht ganz korrekt zut sein. Jedenfalls erlaeutert der Artikel von IBM das Problem etwas anders. Allerdings setzten beide Artikel mehr Hardwarewissen vorraus, als ich es besitze. -- sparti 23:15, 14. Jul. 2008 (CEST)

Merkwürdige Referenzen, die hier hineinkopiert wurden. Das Singleton-Antimuster ist doch mehr als bekannt, und sehr verbreitet. Wieviele Entwickler sind nur darauf reingefallen. Die Diskussion ist umso unterhaltsamer, als dass der im Kommentar erwähnte Autor gar nicht der Autor ist (ein kurzer Blick auf die Historie gibt Aufschluss) --84.135.117.114

Diva

Man beachte [5] (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)

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)

Management nach Zahlen

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.(nicht signierter Beitrag von Ogni42 (Diskussion | Beiträge) 11:50, 23. Okt. 2008)

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)

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)

Die Welt gedeutet aus der Sicht eines Entwicklers

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), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Brooksches Gesetz

Nur eine kleinigkeit: es sind (n^2-n)/2 KommunikationsPARTNER, nicht KommunikationsPAARE. Bitte noch korrigieren. -- Georg (01:33, 2. Aug. 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Hi. Danke für den Hinweis. Aber wer oder was hindert dich daran, es selbst zu korrigieren? --j ?! 19:00, 5. Aug. 2009 (CEST)

Deutsche Übersetzungen

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))

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)

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)

Crocodile Management

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))

:D das ist doch mal wissenschaftliche Arbeit vom feinsten. "Quellen: Diverse - siehe z.B. Google." Ich kann nicht mehr, haste das auch in deinem Info-Referat in der Montagsdoppelstunde verwendet? (nicht signierter Beitrag von 2A00:FE00:4103:1:0:0:0:100 (Diskussion | Beiträge) 02:48, 5. Feb. 2016 (CET))

Antimuster

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)

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)

Programmer Interrupt

Die Relevanz der Aussage, dass ein Programmierer häufig nicht länger als zwei Stunden am Stück ununterbrochen Arbeiten kann ist anzuzweifeln.

1. Würde er damit gegen zum Beispiel gege die in Deutschlang geltend Bildschrmarbeitsplatzverordnung verstoßen, welche regelmäßige Pausen vorsieht.

2. Gibt es genügend Zeitmanagement Formen (Bsp.) welche definitiv nicht erfordern, dass ein Programmieren Stundenlang Pausenlos und ununterbrochen Arbeitet.

Vorschlag:

Verdeutlichen, dass es hierbei darum geht, dass der Programmierer Feste Zeitabschnitte von sinnvoller Länge benötigt, in denen er nicht unterbrochen werden sollte.

Pilze gibt's schon länger

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))

spanische und englische Theorie des Managements

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))

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)