Diskussion:Don’t repeat yourself
Löschen die erste
Bearbeiten"Redundant vorhandene Informationen sind schwierig zu pflegen, ... "
Da denk ich an den Haufen Postwurfsendungen unten im Hausflur. Und an die ganzen Gene in mir. Eine redundant vorhandene Information : Morgens geht die Sonne auf.
" ... , da Konsistenz zwischen den einzelnen Duplikaten gewährleistet sein muss."
Wat mutt dat mutt. Redundanz zusammen mit leichter Inkonsistenz (Rauschen, Noise) wirkt sich laut Informationstheorie doch positiv auf die Übertragunsstabilität aus, oder?
"Bei Systemen, ..., verursacht eine Änderung ... keine anderen ... Teile ?!"
Entweder ist das Nonsens oder barsch aus einem Zusammenhang gerissen den es hier entbehrt.
Alles in allem erscheint dieser Artikel als schlecht formulierter, nachgeplapperter Merksatz aus einem Informatikgrundkurs. Nicht weiter relevant. Oder ist es nur Werbung für : 'The Pragmatic Programmer ?' -- 88.74.57.90 00:43, 9. Jul. 2007 (CEST)
- First off: Wer Löschanträge aus dem Nichts heraus stellt, sollte sich anmelden. Ich möchte wissen, mit wem ich es zu tun habe. Zweitens: Löschantragbausteine ohne Löschdiskussion ist unlustig.
- Zu (1): Ja. Schwierig zu pflegen. Wer weiß, wie oft der von dir angeführte Satz mittlerweile aufgeschrieben wurde. Wenn sich das jemals ändern sollte, wird es ein Aufwand, alle Stellen zu finden und anzupassen.
- Zu (2): Nonsens. Was nützt es, widersprüchliche Informationen zu übertragen ? Dann kann ichs gleich sein lassen.
- Zu (3): Wenn dir eine bessere Formulierung einfällt, den Edit-Knopf hast du ja schon gefunden.
- Zu (4): Ich wäre echt erfreut, wenn so etwas in Informatikgrundkursen oder selbst in Informatikstudiengängen gelehrt würde.
- Und beim nächsten mal: Löschantrag begründen, und auf der Löschdiskussionsseite eintragen. Gruß, --Peritus 19:19, 9. Jul. 2007 (CEST)
- Bitte um Entschuldigung für meine gestrige Ausdrucksweise.
- Zu (1): Wär es möglich im Satz "Redundant...." Information durch Daten/ Datensatz zu tauschen?
- Zu (2): Nonsens: Mal ehrlich: Was soll der Satz "Bei Systemen ..." bedeuten?
- Zu (3): In Anlehnung an die englische Version zwei Korrekturvorschläge:
- - verursacht durch beeinflusst (zur Not auch verändert) ersetzen und gerne auch Teile durch Elemente (Systemteil versus Systemelement).
- - ... , verursacht eine Änderung an einer einzigen Stelle keine Änderungen an anderen logisch nicht-betroffenen Stellen.
- Zu (4): Jetzt machst du mir aber Angst.
- MfG, -- Phillippe 22:27, 9. Jul. 2007 (CEST)
- Bitte um Entschuldigung für meine gestrige Ausdrucksweise.
- Willkommen in der Wikipedia! Wie du sicher gemerkt hast, ist der erste Satz stark an dem englischen Artikel orientiert, dessen Übersetzung er ist. Zu (1): Klar, go ahead, change it. Zu (2): Du hast recht, ich werde mal schauen, ob ich das deutlicher, beispielhafter im Artikel hinbekomme, aber hier kurz ein Ansatz dazu: Wenn du in Systemen (um Code und DBMS einzuschließen) Information mehrfach hast und es keinen SPOT gibt (Denormalisierung kann z. B. in Systemen, die stark skalieren (müssen) sinnvoll sein), weißt du nicht, welche Vorkommen der Information du jeweils ändern musst, damit das System konsistent bleibt. Nimm zum Beispiel Code, der irgendwie etwas mit XML zu tun hat. Übliche Praxis ist hier, eine Feld-Variable XMLNS_FOOBAR = "http://purl/path/to/uri/xmlns" zu vereinbaren und jedes Vorkommen des Namensraumes durch die Konstante zu ersetzen. Wenn du den Namespace an jeder Stelle selbst einfügst, hast du ein Problem wenn sich dieser ändert. Natürlich gibt es bessere Beispiele, bei denen das ganze wesentlich untransparenter wird, aber ich hoffe du weißt, was ich meine. Zu (3) Verbesserungsvorschläge kannst du jederzeit in den Artikel selbst einfließen lassen. Wenn ich (oder jemand anderes) deinen Edit nicht revertet, ist er akzeptiert. Zu (4): Warum ? Hast vor, einen solches Studium zu ergreifen ? Ich bin echt enttäuscht. Die eigentliche Wahrheit gibts nach wie vor nur im Selbsstudium. Gruß, --Peritus 16:56, 11. Jul. 2007 (CEST)
WET
BearbeitenPaul Barry hat ja mal das WET principle dagegengesetzt: (nicht nur nass statt trocken, sondern auch ) Write Everything Twice, siehe http://paulbarry.com/articles/2009/04/01/write-everything-twice-and-because-what-if-i-need-it-later -- 83.97.72.14 18:21, 18. Nov. 2011 (CET)
- Es gibt mit Sicherheit noch viele Prinzipien... Und? --P.C. ✉ 18:24, 18. Nov. 2011 (CET)
- Manche sind für die WP relevant, manche nicht. Siehe z.B. KISS-Prinzip --Sebastian.Dietrich ✉ 19:26, 18. Nov. 2011 (CET)
Artikeltitel
BearbeitenGemäß allgemeiner orthografischer Regeln sollte der Artikel wohl eigentlich den Titel Don't repeat yourself anstatt Don’t repeat yourself tragen (falls es unersichtlich ist: Apostroph vs. Accent). Ersteres ist momentan nur eine Weiterleitung, aber wenn dann sollte die Weiterleitung in die andere Richtung gehen. --Moritz schlarb (Diskussion) 11:07, 30. Sep. 2012 (CEST)
- Ich sehe das auch so. - Wer fühlt sich für den Artikel verantwortlich? --Abubiju (Diskussion) 11:34, 30. Sep. 2012 (CEST)
- Hoffentlich jeder - ich machs dann mal (zuerst Weiterleitung löschen lassen dann Weiterleiten) --Sebastian.Dietrich ✉ 20:01, 30. Sep. 2012 (CEST)
- Bitte Apostroph#Digitale Typografie beachten: Don’t ist mitnichten ein Akzentzeichen, sondern ein typographisch korrekter Apostroph, in Don't findet man hingegen ein Ersatzzeichen. … «« Man77 »» Originalsignatur ohne Klammerzusatz 20:10, 30. Sep. 2012 (CEST)
- Hoffentlich jeder - ich machs dann mal (zuerst Weiterleitung löschen lassen dann Weiterleiten) --Sebastian.Dietrich ✉ 20:01, 30. Sep. 2012 (CEST)
Rule of Three
BearbeitenFalls jemand Zeit und Lust hat, könnte er/sie bei Gelegenheit die Rule of Three in den Artikel einbauen. --the one who was addicted (#) 10:48, 27. Feb. 2015 (CET)
Begriff „Single Source“
BearbeitenDie im Artikel beschriebene Thematik verknüpfe ich auch mit „Single Source“, vermisse aber diesen Begriff im Text. Ist der nicht auch im Deutschen so verbreitet – und zwar allgemeiner als in Single Source of Truth beschrieben –, dass er zumindest an irgendeiner (geeigneten ;-) Stelle mal erwähnt werden sollte ?! --rolf_acker (Diskussion • Beiträge • Logbücher) 17:24, 5. Dez. 2018 (CET)
SPOT falsch dargestellt
Bearbeiten"Während das DRY-Prinzip die Vermeidung von Redundanz zum Ziel hat, hat das SPOT-Prinzip den Umgang mit (gewollter) Redundanz zum Gegenstand."
Vergleiche dazu 1. Abschnitt engl. Artikel zu Single Point of Truth:
"In information science and information technology, single source of truth (SSOT) architecture, or single point of truth (SPOT) architecture, for information systems is the practice of structuring information models and associated data schemas such that every data element is mastered (or edited) in only one place, providing data normalization to a canonical form (for example, in database normalization or content transclusion)."
Es nicht bei SPOT nicht um gewollte Redundanz. --80.135.251.30 20:43, 23. Nov. 2024 (CET)
Lieber Anonymus,
Du schreibst: „Es nicht bei SPOT nicht um gewollte Redundanz.“ Ich vermute, Du wolltest stattdessen schreiben „Es handelt sich bei SPOT nicht um gewollte Redundanz.“ Ziel von SPOT ist, im Falle von nicht vermeidbarer Redundanz einen einzigen Speicherort für ein Datum zu haben, auf den Verlass ist. Dies kann z.B. mittels eines Data Warehouse erreicht werden. Siehe hiezu folgenden Passus aus der Quellenangabe im WP Artikel SPOT: SPOT beim Data Warehousing
„Bei verteilten Daten ist allerdings zu beachten, dass es einen „single point of truth“ gibt – eine Stelle, an der alle Daten korrekt vorhanden sind. Als Lösung hierfür kann man eine zentrale Datenbank nutzen, die von allen Systemen beschickt und gefragt wird. Aufgrund dieses „hot spots“ sollte man hier besonders auf die Qualität und die Performanz der eingesetzten Technik achten.“
Daher schlage ich folgende Formulierung vor:
Während das SPOT-Prinzip den Umgang mit gegebener Redundanz zum Gegenstand hat und darauf abzielt, einen Ort mit verlässlichen Daten zu bekommen, zielt das Don’t-repeat-yourself-Prinzip auf die Vermeidung von Redundanz.
Wenn bis zum 28.11.2024 keine Einwände kommen, werde ich die Änderung im WP-Artikel DRY vornehmen.
Ich grüße Dich freundlich-tzeh (Diskussion) 11:08, 25. Nov. 2024 (CET)
Die genauere Beschreibung des Prinzips durch den Urheber fehlt
Bearbeitenaus dem engischen Artikel
The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.
-> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system <- das ist die Bedeutung, zumindest in der Softwareentwicklung. --80.135.251.30 21:09, 23. Nov. 2024 (CET)
Die Quellenangabe 4 passt nicht zum Textabschnitt
Bearbeiten"DRY ist ein Grundprinzip in Andy Hunts und Dave Thomas’ Buch Der pragmatische Programmierer. Darin schlagen sie vor, DRY auch für Datenbank-Beschreibungen, Tests, Skripte und Dokumentation anzuwenden. [4]"
"[4] Neal Ford: Produktiv programmieren. O’Reilly Verlag, S. 6 Online" --80.135.251.30 21:18, 23. Nov. 2024 (CET)