Mit dem einzigen Verantwortung Prinzip in der „realen Welt“

Question

Ich mag im Grunde eine Vorstellung von dem Prozentsatz der Menschen bekommen, die denken, es ist sinnvoll, das Einzel Prinzip Verantwortung in der realen Welt Code und zu verwenden, wie viele tatsächlich tun. In Podcast #38 spricht Joel darüber, wie nutzlos dieses OOP-Prinzip die reale Welt ist; und weiter, dass dies zeigt, wie Leute wie Onkel Bob wahrscheinlich nicht-triviale Systeme geschrieben haben.

Ich habe persönlich eine große Rolle in einigen Softwareprojekten geschrieben oder gespielt, bin aber erst in meiner jungen Karriere auf dieses Muster gestoßen. Ich liebe den Klang dieses Prinzips und würde wirklich gerne damit anfangen. Ich fand Joels Argumentation im Podcast ziemlich schwach (wie auch andere, wenn man die Blogkommentare here weiterliest). Aber, ist da etwas Wahres dran?

Was denkt die Community?

Answer 1

Ich habe einige Erfahrung mit SOLID Prinzipien und meine Erfahrung war hauptsächlich gut. Ich habe auch den Podcast gehört und es hört sich so an, als hätten weder Jeff noch Joel irgendwas von dem, worüber sie reden, lange genug probiert, um die Vorteile wirklich zu beurteilen.Das Hauptargument dagegen lautet wie gewöhnlich "Sie schreiben mehr Code". Wenn ich mir anschaue, was ich mache, schreibe ich 10 oder 20% mehr Code (normalerweise Schnittstellendefinitionen), aber da alles stark entkoppelt ist, ist es viel wartungsfreundlicher. Ich habe selten Situationen, in denen Änderungen in einem Teil meiner Anwendung andere Teile brechen. Der 20% Extra-Code, den ich pflegen muss, zahlt sich also aus.

Jeff verpasste auch die Qualität des Codes. Er sieht die Code-Qualität nicht als großen Vorteil für den Kunden. Und er hat recht, dem Kunden ist es egal. Der Kunde kümmert sich darum, dass neue Funktionen schnell implementiert werden, und hier kommt die Codequalität ins Spiel. Ich habe festgestellt, dass sich die Investition, die Codequalität so hoch wie möglich zu halten, immer innerhalb weniger Monate bezahlt gemacht hat. Hohe Qualität = geringe Wartung.

Ich stimme ihnen zu, dass wie alles muss man pragmatisch über diese Dinge sein. Wenn Sie etwas liefern müssen, dann machen Sie es schnell und schmutzig. Aber danach aufräumen.

Answer 2

Ich habe Joels Kommentare nicht gelesen oder gehört, also kann ich diese nicht kommentieren.

Ich denke, Sie müssen das Prinzip der einheitlichen Verantwortung in Bezug auf ein Ziel betrachten, anstatt eine strenge Anforderung. Wie bei vielen Dingen in der Softwareentwicklung gibt es Ideale, die angestrebt werden sollten, aber wenn Ihr Code keinen monetären Nutzen oder Kosten hat, müssen Sie pragmatisch die Bedürfnisse Ihrer Kunden erfüllen.

Answer 3

In der Praxis ist es sehr schwierig, in OO-Situationen echte SRP zu erhalten. Betrachten Sie eine Klasse, die in einem komplizierten System existiert. Es hat wahrscheinlich nur eine geschäftliche Verantwortung (z. B. das Drucken eines Berichts), aber es wird intern viele andere Verantwortlichkeiten haben, die gegen reine SRP-Ideale wie Protokollierung und Ausnahmebehandlung verstoßen. Wenn Sie Ihren Protokollierungsmechanismus erheblich ändern, müssen Sie wahrscheinlich die Aufrufe Ihrer Druckklasse ändern.

Aus diesem Grund wurde AOP konzipiert. Wenn Sie es verwenden, müssen Sie nur die Protokollierungsklassen ändern, um die Protokollierung zu ändern.

Es ist gut, aus offensichtlichen Gründen nach geschäftsorientiertem SRP zu streben, aber für ausreichend komplizierte Systeme werden Sie niemals echte SRP in OOP erhalten. AOP, sicher, aber nicht OOP.

Ich habe keine Ahnung, ob das Joels Argumentation ist, aber so würde ich die Idee angehen.

Answer 4

Im Allgemeinen stimme ich mit den SOLID-Prinzipien überein, aber Sie müssen sie auch in den Kontext aufnehmen. Wenn Sie einen Proof-of-Concept schreiben, sind die SOLID-Prinzipien weniger anwendbar.

Auf der anderen Seite, wenn Sie ein Produkt mit einer Lebensdauer von Jahren entwickeln, dann sollten Sie besser die SOLID-Prinzipien betrachten und anwenden. Sonst wird es dem Unternehmen viel Geld in Sachen Produktivität kosten.

In Bezug auf Joel und seine Kommentare hat er einen gültigen Punkt. Manchmal muss das Produkt versendet werden oder das Unternehmen versagt. So ist es halt.

Als Entwickler ist es Ihre Aufgabe, das Produkt zu liefern, aber nur weil es eine enge Frist gibt, bedeutet das nicht, dass Sie mit einer schlechten Architektur gehen. Auswahlmöglichkeiten wie die Verwendung von Datasets oder Geschäftsentitäten ist eine einfache Entscheidung und beide haben ähnliche Implementierungsbemühungen, aber auf lange Sicht ist die Entwicklung neuer Features und die Wartung zwischen den beiden drastisch.

Answer 5

Ich arbeite an einem Projekt, das viele verschiedene, schrecklich komplexe Dinge in einem Rahmen tut, der leicht von anderen erweiterbar sein soll.

Zuerst waren die Klassen groß und machten mehrere Dinge. Um diese Verhaltensweisen zu ändern, mussten Sie diese Klassen erweitern. Die Methoden waren alle virtuell und änderten den Zustand des Objekts nicht, also war es ziemlich einfach, dies zu tun.

Aber als das System wuchs, wurde es klarer, dass das Framework mit einer Reihe von monolithischen Objekten enden würde, jedes mit langen Erbketten. Dies führte auch zu unerwarteten Abhängigkeiten - eine abstrakte Methode, die eine Sammlung von Klasse X zur Erzeugung des in einer Basisklasse definierten Objekts Y benötigte, diktierte, dass JEDER es tun musste, auch wenn es für die Hälfte des Vererbungsbaums keinen Sinn ergab. Dies führte auch zu massiven Klassen, die zig Unit-Tests erforderten, um eine Codeabdeckung von über 80% zu erreichen, und die Komplexität war so groß, dass Sie nicht sicher waren, ob Sie alles richtig abgedeckt haben. Es war offensichtlich, dass dieses Design den Rahmen sehr starr und unflexibel machen würde.

Also haben wir alles entlang SRP-Linien neu gestaltet. Sie haben Ihre Schnittstelle, eine Basisklasse und möglicherweise eine oder mehrere Implementierungsklassen. Jeder war zusammengesetzt von verschiedenen Objekten, die Schlüsselfunktionen des Gesamtprozesses durchgeführt. Wenn Sie einen Teil ändern wollten, überschreiben Sie eine Methode nicht, Sie würden ein anderes Objekt erzeugen, das die erforderliche Schnittstelle/Basisklasse erweitert und seinen Job anders ausgeführt hat. SRP wurde sogar in die Argumente und Rückgabewerte der Klassenmethoden aufgenommen. Für die Teile des Systems, die flexibel sein müssen, statt Sammlungen der X-Klasse zu übergeben, die zur Herstellung von Y-Objekten verwendet werden, wurde eine Klasse erstellt, um den Produktionsprozess von Y-Objekten einzukapseln. Komponenten im System würden dann diese Produzenten herumreichen, sie mit anderen kombinieren (die Verantwortung der Produzenten), und sie schließlich verwenden, um Y zu produzieren. Dies ließ zu, dass verschiedene Arten von Erzeugern geschaffen wurden, die alle genau behandelt werden konnten das gleiche, obwohl sie sehr unterschiedliche Dinge getan haben. Der Umzug hat auch die Codebasis jeder Klasse drastisch reduziert und sie VIEL einfacher zu testen gemacht.

Ich würde sagen, dass es als neuer Entwickler SEHR SCHWER ist, alles auf dieses Niveau herunter zu brechen. Sie müssen fast einen großen Schlammball schreiben, verstehen, wie es funktioniert, und es dann als verschiedene Komponenten neu gestalten, wobei jeder die Verantwortung für einen Teil des Ganzen übernimmt.

Answer 6

Ich denke, dass es möglich sein sollte, eine einfache einzeilige Hauptverantwortung für alle Klassen zu schreiben. Das Wort "und" in diesem One-Liner ist normalerweise kein gutes Zeichen. Die einzelne Verantwortung läuft dann oft darauf hinaus, die richtige Abstraktion auszuwählen.

GUI in der Nähe von Klassen neigen dazu, GUI widerspiegeln und haben die alleinige Verantwortung, "Gui für XXXX". Feiglings Lösung ..

Answer 7

Ich denke, der größte Vorteil eines disziplinierten OO-Entwicklers und die Einhaltung der SRP wann immer möglich sind die Einfachheit der Testbarkeit und Wartung, so würde ich sagen, SRP ist ein gutes Ziel für jedes System, das getestet/gewartet wird , alles außer einem Wegwerfsystem).

Answer 8

Das größte Problem mit einigen der vielen Programmiertheorien ist, dass sie sich darauf konzentrieren, dass gute Attribute im Code gute Attribute für Code sind. Sie haben Recht, weil sie von Natur aus richtig sind und daher nicht besonders nützlich sind.

Ja, Code sollte gut geschrieben sein, und ja, Dinge sollten nicht schrecklich wiederholt werden, und ja, Änderungen sollten keine seltsamen Brüche an unerwarteten Orten verursachen. Aber am Ende des Tages ist ein wirklich einfacher, wirklich konsistenter Code, der die Lösung in einer einfachen, leicht verständlichen Weise ausdrückt, weit mehr wert als ein großes komplexes System, das einige strenge Prinzipien erfüllt. Als Industrie tendieren wir dazu, gute Ideen viel zu weit zu bringen und eine Menge unnötiger Komplexität in der Suche nach der "richtigen" Lösung, nicht der besten, zu schaffen.

Paul.

Answer 9

Ich denke, SOLID-Prinzipien entsprechen manchmal nicht der natürlichen/Geschäftslogik, die man normalerweise beim Entwerfen von Klassen anwendet. Robert C. Martin hat ein Beispiel für Rectange- und Square-Klassen aufgezeigt (Square sollte kein Nachkomme von Rectangle sein).

http://www.hanselminutes.com/default.aspx?showID=163

Ich bin nicht sicher, dass es in Bezug auf SRP aber die Idee ist das gleiche. SOLID-Prinzipien können zu kontraintuitiven Entscheidungen führen, und es ist schwer, diese Barriere zu überwinden.

Für mich ‚Leitlinien‘ ist passenderen Namen als ‚Grundsätze‘.