Diskussion:Single-Responsibility-Prinzip

Änderung der Übersetzung

Die ursprüngliche Übersetzung "Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern." ist m.M.n. falsch. Sie vermittelt den Eindruck, das Ändern der Klasse ist im Sinne vom Editieren des Codes zu verstehen. Das ist aber nicht korrekt. Die Aussage "There should never be more than one reason for a class to change." bezieht sich aber nicht auf den Code, sondern auf den Zustand der Klasse zur Laufzeit. Daher empfinde ich die Anpassung "für eine Klasse sich zu ändern" als verständlicher und aussagekräftiger. Das wird auch deutlich, wenn man das Paper von R.C. Martin beachtet. Dort geht es nicht um das Editieren der Klassen, sondern um ihren Zustand zur Laufzeit.

Siehe auch: http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
SRP The Single Responsibility Principle
A class should have one, and only one, reason to change.

In seiner Publikation Principles of Object Oriented Design verwendet R.C. Martin auch den Ausdruck "A class should have only one reason to change." (Eine Klasse sollte nur einen Grund haben sich zu ändern.). Und dieses stimmt dann auch mit der angepassten Übersetzung überein. (nicht signierter Beitrag von Arkord (Diskussion | Beiträge) 12:26, 10. Jan. 2015 (CET))

Das kann aber nicht damit gemeint sein. Klassen haben keinen Zustand. Den Zustand haben Objekte, aber keine Klassen. Wenn sich Klassen zur Laufzeit ändern, dann mit ganz anderen, hier sicher nicht gemeinten Mechanismen (Reflexion (Programmierung)).

Nimm den Satz "Secondly, if a change to the GraphicalApplication causes the Rectangle to change for some reason, that change may force us to rebuild, retest, and redeploy the ComputationalGeometryApplication." Eine Änderung des Zustandes zur Laufzeit benötigt keinen rebuild etc.

Oder nimm den Satz "If you can think of more than one motive for changing a class, then that class has more than one responsibility."

Diese Sätze (und der ganze Artikel) zeigen, dass mit "to change" ein passives "to be changed" gemeint ist. Also von einem Entwickler gemachte Änderungen im Code.

Ein Prinzip, dass aussagen würde, dass es nur einen Grund geben darf, dass sich der Zustand eines Objektes zur Laufzeit ändert wäre auch Schwachsinn. Ein Rechteck z.B. sollte sich ändern dürfen, weil sich seine Farbe, seine Größe, seine Position etc. ändert. Das alles in eigene Klassen (mit konsequenterweise jeweils nur einem Attribut ohne Relationen) zu trennen würde fundamental der Objektorientierung widersprechen. --Sebastian.Dietrich ✉ 23:22, 10. Jan. 2015 (CET)

Bereich: Definition

Eine Definition damit anzufangen was es nicht ist, ist keine gute Lehr-Strategie. Sucht jemand nach einer Definition ist sein Geist offen, um zu erfahren wie es ist.

Als erstes zu erfahren was viele Denken, was aber eigentlich falsch ist, verwirrt hier nur. Habe ich als Leser von dieser falschen Denkweise noch nicht gehört, muss ich diese erst erfassen, verstehen und dann negieren (ohne im Hinterkopf zu haben, wie es denn eigentlich sein sollte). Erst dann kann ich mich der eigentlichen Erklärung zuwenden. Viel besser ist es sofort zu erklären was es ist, und erst anschließend, ergänzend erklären, welche falsche Vorstellung sich u.a auch weit verbreitet hat! (nicht signierter Beitrag von Rethus (Diskussion | Beiträge) 09:50, 28. Okt. 2019 (CET))

Einzelnachweis 3 ist veraltet

Der im dritten Einzelnachweis verlinkte Artikel ist über die angegebene URL nicht mehr aufrufbar. Auf https://drive.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/view (so auf http://butunclebob.com verlinkt) findet man hingegen den entsprechenden Artikel (lässt sich allerdings nicht einfügen, da es ein Google-Drive-Links ist). (nicht signierter Beitrag von 134.155.22.191 (Diskussion) 11:12, 30. Nov. 2019 (CET))