SoC vs. SRP
Laurin Stoll
Mir muss mal jemand auf die Sprünge helfen. Irgendwie ... sehe ich
einfach den Unterschied zwischen SoC und SRP nicht. Wieso brauchen wir
da beidem im Wertesystem? Die vermitteln doch beide das selbe. Eine
Klasse soll eine klar definierte Aufgabe haben - PUNKT.
Oder?
Alexander Zeitler
Ich denke, das Beispiel hier ist nicht das schlechteste, um den Unterschied
zu verdeutlichen:
http://weblogs.asp.net/arturtrosin/archive/2009/01/26/separation-of-concern-
vs-single-responsibility-principle-soc-vs-srp.aspx
Gruß
Alex
Laurin Stoll
On 8 Apr., 12:07, "Alexander Zeitler" <a...@alexonasp.net> wrote:
> Hallo,
>
> >Mir muss mal jemand auf die Sprünge helfen. Irgendwie ... sehe ich
> >einfach den Unterschied zwischen SoC und SRP nicht. Wieso brauchen wir
> >da beidem im Wertesystem? Die vermitteln doch beide das selbe. Eine
> >Klasse soll eine klar definierte Aufgabe haben - PUNKT.
>
> Ich denke, das Beispiel hier ist nicht das schlechteste, um den Unterschied
> vs-single-responsibility-principle-soc-vs-srp.aspx
>
> Gruß
>
> Alex
Sebastian Jancke
Der Unterschied zwischen Separation of Concerns und Single
Responsibility Principle sind gravierend. Bevor ich den Unterschied
beschreibe möchte ich noch sagen: Ich beziehe mich auf Uncle Bob's
Definition des SRP und ich lege zunächst als Paradigma OO zu Grunde.
SRP: Every class should only have one reason too change.
Ich denke es ist klar, was dies bedeutet: Jedes Objekt oder jede Klasse
von Objekten soll genau eine eindeutige Verantwortlichkeit haben. Damit
gibt es nur einen Grund, ein Objekt zu ändern.
Separation of Concerns: Lässt sich in einem Satz schlecht
zusammenfassen. Kurz gesagt geht es auf Dijkstra zurück der es in einem
seiner Briefe (siehe ACM Archiv) benannte. Es geht darum, sämtliche
Belange eines "Problems" zu trennen, denn erst dann ist es möglich über
einen dieser Belange exakt nachzudenken (was laut Dijkstra dann erst
logisches effizientes Denken über Probleme ermöglicht). Ich hoffe ich
habs nicht verbockt mit diesem Versuch einer Zusammenfassung ;-)
Was heißt SoC für Software? Bei der Dekomposition eines Problems oder
genereller einer Anwendung in verschiedene Module soll jeder Belang
einen festen Platz haben, getrennt von allen anderen Belangen. Dies
bedeutet, dass ich zunächst oftmals anhand meiner Domäne eine
Dekomposition durchführem also in verschiedene Funktionalitäten zerlege
(damit also einige der Belange an das System).
Wenn ich entlang meiner Domäne eine Dekomposition durchführe, kann ich
dies nicht mehr entlang meiner Infrastruktur tun. Dieses Phänomen ist in
der Forschung als "Tyranny of the dominant decomposition" beschrieben
worden. Als Beispiel kann ich mir eine CD-Regal zu Hause vorstellen. Ich
kann die CDs nach Namen sortieren, um schnell eine CD eines bestimmten
Künstlers zu finden. Ich kann dann aber zB nicht schnell CDs eines
Genres finden, dafür müsste ich nach Genres sortieren. Dann kann ich
aber nicht mehr schnell nach einem Namen suchen. Beide Belange
überkreuzen sich. Mehr zu dem Beispiel:
http://sjancke.blogspot.com/2008/09/aspektorientierung-der-natrliche-nchste.html
Ich kann infrastrukturelle Belange wie Sicherheit, Persistenz oder auch
Updates/Benachrichtigungen (-> Observer Variationen) zwar in eigene
Module kapseln, letztlich kann ich diese Belange aber nicht explizit
trennen, weil die Module der domäne immer wieder Zugang dazu brauchen.
Deshalb nennt man solche Belange "Crosscutting Concerns", weil sie in
der Dekomposition orthogonal zu den Belangen der Domäne stehen. Am
Beispiel der "Updates/Benachrichtigungen" sieht man auch sofort, dass
dies nicht nur Infrastruktur betrifft sondern auch Teile der Domäne selbst.
Kann ich also Separation of Concerns im Paradigma der Objektorientierung
erreichen? Erinnern wir uns an das genannte Phänomen der "Tyranny of the
dominant decomposition". Damit ist klar: es geht nicht. Damit sind wir
dann bei einem meiner Lieblingsthemen angelangt: erweitern wir unser OO
Paradigma um die Konzepte des Paradigmas Aspektorientierung (AO), so
geht es schon.
Mehr Informationen und das ganze (SoC, Tyranny, ...) ausführlich gibt es
hier:
http://sjancke.blogspot.com/2008/09/aspektorientierung-der-natrliche-nchste.html
http://portal.acm.org/citation.cfm?id=302457 (_das_ Paper zu Tyranny...)
http://www.research.ibm.com/hyperspace/ (zugehöriges Projekt)
http://de.wikipedia.org/wiki/Cross-Cutting_Concern
So, dass solls nun gewesen sein, AO ist zwar ein Lösungsansatz, aber ich
wollte ja SoC diskutieren ;-)
-Sebastian
Ralf Westphal
unbefriedigt.
Ich glaube, der Grund dafür liegt in zweierlei:
1. In dem wechselseitigen Versuch, SoC und SRP auf derselben Ebene
anzusiedeln und dann zu entscheiden, ob sie dasselbe sind oder eben
nicht. Da kann man dann nämlich quasi nur noch binär entscheiden.
2. In einer Unterspezifikation von "Belang" und "Änderungsgrund".
Was ist denn ein Belang (Concern) im Unterschied zu einer
Verantwortlichkeit (Responsibility)?
Was ist ein "Änderungsgrund"? Wenn ich eine Klasse habe, die User
Settings verwaltet für Bildschirmfarbe und Hintergrundbild, was ist
dann der eine Grund, der mich zu einer Änderung veranlassen dürfte?
Ich finde so eine Klasse sinnig, weil sie eine Verantwortlichkeit hat:
User Settings Verwaltung - aber falls ich morgen Bildschirmfarben
nicht mehr als Integer, sondern als Enum verwalten möchte oder das
Hintergrundbild nicht mehr als Bitmap, sondern nur noch als Dateiname,
dann sind das für mich zwei Änderungsgründe.
Um die Verwirrung aufzulösen, hilft nur - so glaube ich -,
unterschiedliche Ebenen einzuführen: SoC und SRP stehen in einer
Hierarchie. Und darin steht SRP über SoC. SRP ist (für mich)
allgemeiner. So allgemein wie DRY. SRP sagt: Vermische nicht die
Definition (!) von Funktionseinheiten, die ganz unterschiedlichen
Zwecken dienen. Nutzen darf Code Funktionseinheiten unterschiedlicher
Zwecke natürlich. Das geht ja auch nicht anders.
Wie man nun Zwecke bezeichnet, als Responsibility oder Concern, das
ist recht egal. Und es kommt auch nicht darauf an, ob eine
Funktionseinheit eine Methode oder Klasse oder Assembly ist.
Mit dieser Hierarchisierung ist zweierlei erreicht:
-Wir können uns fragen, ob wir SoC noch brauchen. Wenn ja, wasfüreine
spezielle Verantwortlichkeit ist dann Concern? Inwiefern unterscheidet
sich Concern in punkto Definition und/oder Nutzung von anderen
Verantwortlichkeiten?
-Wir kommen weg von dem merkwürdigen "Änderungsgrund", der eingeführt
wurde, um Concern und Responsibility überhaupt zu unterscheiden.
Noch kurz was allgemeines: Verantwortlichkeit (as in SRP) sind aus
genügend großer Entfernung immer "Single". Beispiel: Wenn ich eine
Buchhaltungsanwendung betrachte, dann hat die 1 Verantwortlichkeit:
Buchführung. Wenn ich dann aber reinzoome, dann sehe ich darin
unterschiedliche Verantwortlichkeiten, die zusammenspielen, z.B.
Presentation Layer, Business Logic, Data Access. Wenn ich dann aber
noch weiter reinzoome, dann teilen die sich weiter auf in feinere
Verantwortlichkeiten, z.B. Data Access in Metadatenverwaltung, Entity
Retrieval, Aggregationen.
Das bedeutet: Um zu beurteilen, ob etwas nur eine Verantwortlichkeit
hat, ist der Betrachtungsabstand zu berücksichtigen. Und es kann sich
im Laufe der Zeit ergeben, dass neue Verantwortungen entstehen, wenn
die Funktionalität zunimmt, d.h. sich der Betrachtungsabstand zu einem
Problem verkleinert. Das kann man auch Differenzierung nennen. Am
Anfang sind "Funktionseinheiten" (oder auch Organisationen) gewöhnlich
recht undifferenziert. Mit der Zeit differenzieren sie sich dann aus.
Aus Flexibilität wird dadurch Effizienz.
-Ralf
Laurin Stoll
@Sebastian: Danke für die ausführliche Erklärung - das ist in der Tat
nicht so hervorgekommen in dem verlinkten Beispiel.
@Ralf: Du sprichst mir aus dem Herzen. Ich kanns nicht mehr hören:
"Nur einen Änderungsgrund." Ich finde diese Definition so schlecht wie
undifferenziert. SRP und SOC muss man nicht immer auf der gleichen
Ebene ansiedeln. Wenn man SRP befolgt hat man SOC inklusive. SOC
ansich nochmal zu formulieren finde ich aber nicht schlecht, da ich
für Explizität (gibts das Wort!?) bin.
Leider finde ich die definitionen im CCD Wiki diesbezüglich genau
etwas schlecht....
Besten Dank für eure Mühen :)
Laurin
Ralf Westphal
> etwas schlecht....
wir arbeiten an einer neuauflage...
stay tuned! :-)
-ralf
Sebastian Jancke
Laurin Stoll schrieb:
> Hallo zusammen,
> Wenn man SRP befolgt hat man SOC inklusive.
Wie bereits erwähnt kommt dies stark auf das befolgte Sprachparadigma
an. Ich gehe mal allgemein von OO aus. Und dann bekommt man SoC nicht
inklusive, wenn man SRP befolgt. Ein Objekt kann eine Responsibility
haben, und alle weiteren benötigten Responsibilities durch Aufrufe
weiterdelegieren. Dann kann ich aber trotzdem eine Verletzung von SoC
haben, denn scattering&tangling tritt schon allein durch einen
Methodenaufruf in Kraft. Die Ursache liegt in der Tyranny of the
dominant decomposition.
Ich sehe SRP und SoC weniger in einer Hirachie und vielmehr orthogonal
zu einander. Änderungsgrund und Concern sind klar definiert und auch
abgrenzbar gegeneinander.
SRP und SoC sind grundverschieden. Jedes Objekt kann genau eine
wohldefinierte Verantwortlich haben. Dennoch muss ich dann zur Erfüllung
bestimmter Aufgaben delegieren. In der Delegation von "gleichen"
Aufgaben an vielen Stellen kann ein Concern versteckt sein
(Standardbeispiele: Tracing, Security, Persistence, ...). Das diese
Concerns alle modularisiert sein sollen, ist Aussage des SoC (für
Software Design).
> Wenn ja, wasfüreine
> spezielle Verantwortlichkeit ist dann Concern?
Ralf, was genau meinst du damit? Sprechen wir von einem bestimmten
Concern und fragen nach seiner speziellen Verantwortlichkeit?
> Wir kommen weg von dem merkwürdigen "Änderungsgrund", der eingeführt
> wurde, um Concern und Responsibility überhaupt zu unterscheiden.
Ich sehe "Änderungsgrund" nur in der impliziten Definition von SRP durch
RC Martin. Für die Definition des Begriffs "Concern" ist dies nicht von
Bedeutung.
-Sebastian
Ralf Westphal
> zu einander. Änderungsgrund und Concern sind klar definiert und auch
> abgrenzbar gegeneinander.
mich ist "änderungsgrund" wenig hilfreich.
eine klasse für den datenbankzugriff mit eine Connect() und eine Load
() methode kann sich aus vielen gründen ändern.
"responsibility" ist vielmehr eine sache im auge des betrachters. sie
hängt auch vom abstand ab, aus dem er darauf schaut. eine ganze
anwendung hat aus genügend großer entfernung betrachtet auch hnur 1
verantwortung.
die hierarchie von SRP und SoC ergibt sich nun für mich daraus, dass
"verantwortlichkeit" ein so allgemeiner begriff ist.
ein parser und ein interpreter und ein logger und ein cache sind alle
klar von einander getrennte verantwortlichkeiten.
aber: (parser, interpreter) und (logger, cache) sind dann nochmal
unterschiedl concerns zugeordnet.
concerns stehen orthogonal zu einander, d.h. für den zweck des einen
concerns braucht man nicht unbedingt den anderen. sie sind unabhängig.
man kann sie komplett getrennt denken.
und auch da kommt es auf den blickwinkel an: im normalen
schichtenmodell ist der datenzugriff kein concern. aber mit ein wenig
mühe kann man persistenz als concern quasi transparent in jeder
schicht einhängen.
> Ich sehe "Änderungsgrund" nur in der impliziten Definition von SRP durch
> RC Martin.
auch "der meister" kann mal daneben liegen ;-)
-ralf
Sebastian Jancke
mit der Orthogonalität von Concerns stimmen wir also (nun?!) überein. Dies wird aber auf der CCD-Seite (derzeit) nicht deutlich. Dort sieht es so aus, als sei SoC nur eine andere Formulierung / ähnliche Definition wie SRP. Ihre Unterschiede (und anderen Zielgruppen) werden nicht deutlich.
-Sebastian
Ralf Westphal
>Dies
> wird aber auf der CCD-Seite (derzeit) nicht deutlich. Dort sieht es so aus,
> als sei SoC nur eine andere Formulierung / ähnliche Definition wie SRP. Ihre
> Unterschiede (und anderen Zielgruppen) werden nicht deutlich.
dem wir grad arbeiten. sozusagen major refactoring :-)
-ralf
Yves Goergen
Nur wenn ich SoC und SRP in einem Satz zusammenfassen sollte, wären beide identisch und somit redundant. Dabei gefällt mir die sehr kurze Beschreibung zu SoC in der Wikipedia am besten: "Verschiedene Elemente der Aufgabe sollten möglichst in verschiedenen Elementen der Lösung repräsentiert werden."
Vielleicht ist das auch alles nur zu theoretisch und hat kaum einen praktischen Bezug? Letztlich sind solche Ideen ja ganz nett, um darüber zu philosophieren (etwas, das ich nicht kann - ich kann mich besser kurz und präzise ausdrücken), aber im Projektalltag muss man sie dann irgendwie anwenden. Und da vermute ich, läuft doch beides auf das selbe raus. Kann mir jemand widersprechen?