Vom STUPID-Code zum SOLID-Code

Ursprünglicher Autor: William Durand
  • Übersetzung
Letzte Woche habe ich in Michelin, in der Firma, in der ich arbeite, einen Vortrag über objektorientierte Programmierung gehalten . Ich habe darüber gesprochen, effizienteren Code zu schreiben, von STUPID zu SOLID Code ! Sowohl STUPID als auch SOLID sind Akronyme und wurden auf lange Sicht ziemlich oft angesprochen. Diese Mnemoniken sind jedoch nicht immer bekannt, daher ist es sinnvoll, diese Informationen zu verbreiten.

Bild

Als nächstes werde ich Ihnen die Prinzipien von STUPID und SOLID vorstellen. Es sollte beachtet werden, dass dies Prinzipien und keine Gesetze sind. Sie als Gesetze zu betrachten, wäre jedoch gut für diejenigen, die ihre Codierung verbessern möchten.

DUMMER Code, im Ernst?


Das mag deinen Stolz verletzen, aber du hast wahrscheinlich schon viel DUMMEN Code geschrieben. Ich auch. Aber was heißt das?

  • Singleton
  • Starke Kopplung / Enge Kopplung
  • Unfähigkeit zu testen
  • Vorzeitige Optimierung
  • Nicht beschreibende Benennung
  • Code-Vervielfältigung

Im Folgenden werde ich auf jeden Punkt näher eingehen. Dies können Transkripte meiner Geschichte in allgemeiner Form gesagt werden.

Singleton


Das Einzelgänger-Muster ist wahrscheinlich das bekannteste und am meisten unterschätzte Entwicklungsmuster. Wissen Sie über das Einzelgängersyndrom Bescheid? In diesem Fall ist die Singleton-Vorlage Ihrer Meinung nach die am besten geeignete Vorlage für den aktuellen Anwendungsfall. Mit anderen Worten, Sie verwenden es überall. Das ist definitiv nicht cool.

Einzelne Elemente sind widersprüchlich und werden oft als fehlerhafte Muster angesehen. Sie müssen sie vermeiden. Tatsächlich ist die Verwendung eines Singletons kein Problem, sondern ein Symptom für ein Problem. Hier sind zwei Gründe, warum:

  • Programme, die den globalen Status verwenden, sind sehr schwer zu testen.
  • Programme, die vom globalen Status abhängen, verbergen ihre Abhängigkeiten.


Aber sollten Sie sie wirklich die ganze Zeit vermeiden? Ich würde ja sagen, weil man mit einem Singleton oft etwas Besseres ersetzen kann. Es ist sehr wichtig, alles statische zu vermeiden, um eine starke Kopplung zu verhindern.

Starke Verbundenheit


Starke Verbundenheit ist eine Verallgemeinerung des Singleton-Problems. Kurz gesagt, Sie sollten die Kommunikation zwischen Ihren Modulen reduzieren. Konnektivität ist ein Maß dafür, wie verwandt Routinen oder Module sind.

Wenn Sie für eine Änderung an einem Modul in Ihrer Anwendung ein anderes Modul ändern müssen, besteht Konnektivität. Beispielsweise instanziieren Sie Objekte in der Klasse Ihres Konstruktors, anstatt Instanzen als Parameter zu übergeben. Das ist schlecht, weil es keine weiteren Änderungen zulässt, z. B. das Ersetzen einer Instanz durch eine Instanz einer Unterklasse, eines Scheinobjekts oder was auch immer.

Stark gekoppelte Module sind schwer wiederzuverwenden und auch schwer zu testen.

Unfähigkeit zu testen


Testen sollte meiner Meinung nach nicht schwierig sein! Nein wirklich. Jedes Mal, wenn Sie keine Komponententests schreiben, weil Sie keine Zeit haben, ist das eigentliche Problem, dass Ihr Code nicht so effizient ist, aber das ist eine andere Geschichte.

In den meisten Fällen wird die Unmöglichkeit des Testens durch starke Kohärenz verursacht.

Vorzeitige Optimierung


Donald Erwin Knut sagte: „Vorzeitige Optimierung ist die Wurzel allen Übels. Nur kostet allein und nicht gut. " In der Tat sind optimierte Systeme viel komplexer als nur das Schreiben einer Schleife oder die Verwendung von Vorinkrementierung anstelle von Nachinkrementierung. Sie werden mit unlesbarem Code enden. Aus diesem Grund wird die vorzeitige Optimierung häufig als fehlerhaft angesehen.

Mein Freund sagt oft, dass es zwei Regeln für die Optimierung einer Anwendung gibt:

  • Mach das nicht;
  • (nur für Profis!) Mach das noch nicht.


Nicht beschreibende Benennung


Es sollte klar sein, aber Sie müssen es trotzdem sagen: Nennen Sie Ihre Klassen, Methoden, Attribute und Variablen richtig. Oh, und schneide sie nicht! Und ja, Sie schreiben Code für Menschen, nicht für Autos. Sie verstehen nicht, was Sie so oder so schreiben. Computer verstehen nur 0 und 1. Programmiersprachen sind für Menschen.

Code-Vervielfältigung


Duplizierter Code ist ineffizient. Wiederholen Sie ihn also nicht und verkürzen Sie ihn und vereinfachen Sie ihn. Schreibe den Code nur einmal!

Nun, da ich erklärt habe, was der DUMME Code ist, könnten Sie denken, dass Ihr Code der DUMME Code ist. Es spielt (noch) keine Rolle. Lassen Sie sich nicht entmutigen, bleiben Sie ruhig und schreiben Sie stattdessen SOLID-Code!

FEST zur Rettung


SOLID ist ein Begriff, der die Konstruktionsprinzipien für effizienten Code beschreibt, die von Robert C. Martin, auch bekannt als Uncle Bob, erfunden wurden.

SOLID bedeutet:

  • Grundsatz der alleinigen Verantwortung
  • Das Prinzip der Offenheit / Nähe
  • Barbara Liskov Substitutionsprinzip
  • Prinzip der Schnittstellentrennung
  • Prinzip der Abhängigkeitsinversion


Grundsatz der alleinigen Verantwortung


Nach dem Single Responsibility Principle (SRP) sollte jede Klasse eine einzige Verantwortung haben. Eine Klasse sollte nur einen Grund haben, sich zu ändern.

Nur weil Sie Ihrer Klasse alles hinzufügen können, was Sie möchten, müssen Sie dies nicht tun. Verantwortlichkeiten helfen Ihnen, Ihre Anwendung besser zu entwickeln. Fragen Sie sich, ob die von Ihnen dargestellte Logik zu dieser Klasse gehören soll oder nicht. Die Verwendung von Ebenen in der App hilft sehr. Teilen Sie die größeren Klassen in kleinere ein und vermeiden Sie die „ göttlichen “ Klassen. Zu guter Letzt schreiben Sie einfache Kommentare. Wenn Sie anfangen, Kommentare zu schreiben, wie in diesem Fall, aber wenn, außer wann, oder, dann machen Sie es falsch.

Das Prinzip der Offenheit / Nähe


Open / Closed-Prinzip (OCP): Entitäten (Klassen, Module, Funktionen usw.) müssen zur Erweiterung geöffnet, zur Änderung jedoch geschlossen sein.

Sie müssen standardmäßig alle Instanzvariablen als privat kennzeichnen. Schreiben Sie get- und set-Methoden nur, wenn Sie sie wirklich brauchen. Ich habe diese Frage bereits in einem früheren Artikel beantwortet, da die neunte Regel der objektiven Gymnastik mit diesem Prinzip verbunden ist.

Barbara Liskov Substitutionsprinzip


Liskov Substitution Principle (LSP): Es sollte möglich sein, jeden Subtyp des Basistyps zu ersetzen.
Schauen wir uns ein Beispiel an. Ein Rechteck ist eine flache Figur mit vier rechten Winkeln. Es hat eine Breite und eine Höhe.

Schauen Sie sich nun den folgenden Pseudocode an:
rect = new Rectangle();
rect.width  = 10;
rect.height = 20;
assert 10 == rect.width
assert 20 == rect.height

Wir setzten nur die Breite der Breite und Höhe der Höhe auf Betreiben des Rechtecks , und dann bestätigen wir , dass beide Eigenschaften korrekt sind. So weit, so gut.

Jetzt können wir unsere Definition verbessern, indem wir sagen, dass ein Rechteck mit vier Seiten gleicher Länge ein Quadrat heißt. Ein Quadrat ist ein Rechteck, also können wir die Square-Klasse erstellen, die die Rectangle-Klasse erweitert, und die erste Zeile oben durch die untere ersetzen:
rect = new Square();

Nach der Definition eines Quadrats ist seine Breite gleich seiner Höhe. Können Sie das Problem erkennen? Die erste Anweisung funktioniert nicht mehr, da wir das Verhalten der set-Methoden in der Square-Klasse an die Definition anpassen mussten. Dies ist eine Verletzung des Barbara-Liskov-Substitutionsprinzips.

Prinzip der Schnittstellentrennung


Prinzip der Schnittstellentrennung (ISP): Viele spezialisierte Schnittstellen sind besser als eine universelle Schnittstelle. Mit anderen Worten, Sie müssen keine Methoden implementieren, die Sie nicht verwenden. Durch die Implementierung von ISP erhalten Sie eine schwache und eine starke Konnektivität.

Wenn es um Konnektivität geht, wird häufig auch Konnektivität erwähnt. Starke Konnektivität bedeutet, ähnliche und verwandte Elemente zusammenzuhalten. Die Kombination von Verbundenheit und Verbundenheit ist eine orthogonale Struktur.

Die Idee ist, die Komponenten so auszurichten, dass die Abhängigkeiten zwischen ihnen möglichst gering gehalten werden.

Beachten Sie, dass dies dem Prinzip der alleinigen Verantwortung ähnelt. Eine Schnittstelle ist ein Vertrag, der einen Bedarf befriedigt. Es ist in Ordnung, eine Klasse zu haben, die verschiedene Schnittstellen implementiert, aber achten Sie darauf, SRP nicht zu verletzen.

Prinzip der Abhängigkeitsinversion


Das Dependency Inversion Principle oder DIP hat zwei Hauptprinzipien:

  • Abstraktionen sollten nicht von Details abhängen.
  • Details sollten von Abstraktionen abhängen.


Dieses Prinzip kann umformuliert werden, wie dieselbe Abstraktionsebene auf einer bestimmten Ebene verwendet werden kann. Schnittstellen müssen von anderen Schnittstellen abhängen. Fügen Sie den Schnittstellensignaturen keine bestimmten Klassen hinzu. Verwenden Sie jedoch Schnittstellen in Ihren Klassenmethoden.

Beachten Sie, dass das Prinzip der Abhängigkeitsinversion nicht mit der Abhängigkeitsinjektion übereinstimmt. Abhängigkeitsinjektion ist, wenn ein Objekt über ein anderes abhängiges Objekt Bescheid weiß. Mit anderen Worten, wir sprechen darüber, wie ein Objekt süchtig wird. Andererseits liegt das Prinzip der Abhängigkeitsinjektion auf der Abstraktionsebene. Darüber hinaus können Klassen mithilfe eines Abhängigkeitsinjektionscontainers automatisch verbunden werden. Dies bedeutet jedoch nicht, dass Sie eine Abhängigkeitsinjektion durchführen. Schauen Sie sich zum Beispiel den Service Locator an .

Verwenden Sie außerdem Schnittstellen, anstatt mit stark verwandten Klassen zu arbeiten. Dies nennt man Schnittstellenprogrammierung . Es reduziert die Abhängigkeit von Implementierungsfunktionen und ermöglicht die Wiederverwendung von Code. Außerdem wird sichergestellt, dass Sie die Implementierung ersetzen können, ohne die Erwartungen dieser Schnittstelle gemäß dem Barbara Liskov-Substitutionsprinzip zu verletzen.

Fazit


Wie Sie wahrscheinlich bemerkt haben, ist die Vermeidung einer starken Konnektivität hier ein Schlüsselelement. Hier gibt es eine Menge Code. Wenn Sie sich zunächst darauf konzentrieren, ihn alleine zu reparieren, werden Sie sofort damit beginnen, besseren Code zu schreiben.

Hier sind einige Ratschläge für Sie. In der Softwareentwicklung gibt es viele Prinzipien. Denken Sie immer nach, bevor Sie Code schreiben, auch wenn Sie all diese Prinzipien nicht verstehen. Nehmen Sie sich Zeit und versuchen Sie zu verstehen, was Sie nicht verstehen.

Ehrlich gesagt ist das Schreiben von SOLID- Code nicht so schwierig.

TL; DR

STUPID ist ein Akronym, das schlechte Erfahrungen in der orientierten Objektprogrammierung beschreibt:

  • Singleton
  • Starke Konnektivität
  • Unfähigkeit zu testen
  • Vorzeitige Optimierung
  • Nicht beschreibende Benennung
  • Code-Vervielfältigung


SOLID ist eine Abkürzung für die fünf Grundprinzipien der objektorientierten Programmierung und des Entwurfs und Engineerings zur Korrektur von STUPID- Code:

  • Grundsatz der alleinigen Verantwortung
  • Das Prinzip der Offenheit / Nähe
  • Barbara Liskov Substitutionsprinzip
  • Prinzip der Schnittstellentrennung
  • Prinzip der Abhängigkeitsinversion


Goldene Regel: Schalten Sie Ihr Gehirn ein!

Jetzt auch beliebt: