Sie bereiten eine Leiche mit SOLID vor

    Wie das Sprichwort sagt: "Es ist verrückt, immer wieder dasselbe zu tun, ohne irgendetwas zu ändern und auf ein anderes Ergebnis zu hoffen." Aber manchmal verwendet man dieselben Ansätze, Aussagen und Handlungen, um ein scheinbar vorhersehbares Ergebnis zu erzielen, und man wundert sich aufrichtig, warum diesmal nichts passiert ist.

    Es gibt einen Bereich, in dem solche Handlungen nicht nur Skepsis hervorrufen, sondern als die einzig wahren dargestellt werden können - objektorientierte Programmierung.

    Wir beginnen, wie erwartet, mit dem schwächsten der Paradigmen von „SOLID-Prinzipien“, die gut sind, dass ich nicht aus Granit herauskomme.

    Machen Sie sich bereit für viele Briefe ... Lassen Sie uns eine kurze Definition geben: SOLID abbr. aus dem Englischen Einzelverantwortung, Open-Closed, Liskov-Substitution, Schnittstellentrennung und Abhängigkeitsinversion. Das heißt eine ziemlich kleine Reihe von Prinzipien aus der ganzen Vielfalt, aber klare Grenzen zwischen dem, was Sie tun können, was am besten nicht zu tun ist und was in Ihrem Projekt genau überarbeitet werden muss.

    Fangen wir an.

    Barbara Liskov Substitutionsprinzip


    L-, LSP-, Liskov-Substitutionsprinzip
    Objekte in einem Programm müssen durch Instanzen ihrer Subtypen ersetzbar sein, ohne die Richtigkeit der Programmausführung zu ändern.

    Eines der schwächsten und unerreichbarsten Prinzipien, nach dem wir eine Abstraktion durch ihren Subtyp ersetzen müssen, und nichts sollte passieren. Es fällt mir sogar schwer, mir etwas vorzustellen, das weiter von der Realität entfernt und von der Definition her unmöglich ist. (Es wäre sehr interessant, die Definition von "korrekte Ausführung des Programms" zu hören, aber wir werden sie nicht brauchen.)

    Für Bücherwürmer
    Die wörtliche Aussage klang ungefähr so:

    Subtype Requirement: Let f(x) be a property provable about objects x of type T. Then f(y) should be true for objects y of type S where S is a subtype of T.

    Sie arbeitet im Allgemeinen nicht mit einem Programm, sondern mit einer Eigenschaft eines Typs. Was natürlich weniger ist, ändert aber nichts an der Essenz. In OOP bestimmen viele Typen den Betrieb eines Programms.

    Ob die Dauer der Vollstreckung als unter die Notwendigkeit fallend angesehen wird, diesem Grundsatz zu folgen. Ja, die Laufzeit der Anwendung ist derselbe Vertrag (dieselbe Eigenschaft) wie die Eingabeparameter und das Ausführungsergebnis sowie die Vor- und Nachbedingungen und eine Liste möglicher Ausnahmen. Oft wird er als schwieriger Teenager nicht beachtet und plötzlich passiert nichts mehr. Nun, wenn es so ausfällt, dann hat das Prinzip aber nichts damit zu tun - reines Glück, es war nicht wirklich notwendig, nicht wirklich gewollt.

    Lass uns weiter gehen.

    Größe der verbrauchten Ressourcen: Speicher, Prozessorzeit, verbrauchte Kerne, Bedarf oder Abwesenheit von Add. Ausrüstung.

    Manchmal erfordert das Ersetzen einer Entität, beispielsweise das Protokollieren von einer Datei in eine Datenbank, nicht triviale Dinge: Verbinden zusätzlicher Bibliotheken, Ändern von Konfigurationsdateien (ich sehe eine Debatte darüber, ob die Konfigurationsdatei Teil dieses Prinzips sein soll oder nicht).

    Wenn Sie natürlich graben, können Sie natürlich die Anforderungen reduzieren: Sie sagen nicht für alle Typen, nicht für alle Eigenschaften und nicht immer. Aber dann ist das Wesen des Prinzips sehr verschwommen. Etwas aus der Kategorie "Sie können nur auf grünes Licht umschalten, aber wenn eine Ampel ausfällt oder Sie keine Autos in einer Entfernung von zwei Kilometern sehen ... oder ein Einhorn fliegt ..."

    Als Designer oder Entwickler gehen wir bereits Risiken ein ( häufig gerechtfertigt) unter Verstoß gegen das Barbara-Lisk-Substitutionsprinzip, wenn wir den Code optimieren oder überarbeiten.

    Dieses Prinzip ist niemals realisierbar , nur das Ersetzen von Int32 durch Int64 macht es bereits nicht realisierbar. Ich hoffe, der umgekehrte Ersatz von Int64 durch Int32 lässt niemanden an seiner Verletzung zweifeln.

    Indem Sie sich fanatisch daran halten, schaffen Sie etwas, das bereits „tot“ ist, weil es bei der Geburt nicht „atmet“ und nicht, wenn es danach nicht atmet. Sie selbst werden mit beneidenswerter Beharrlichkeit alles „Unnötige“ abschneiden, um das Verhalten des Neuen nicht zu ändern. Sobald Sie etwas geschaffen haben, sind Sie dazu verdammt, auch in Zukunft zu schaffen. Herzlichen Glückwunsch, Sie haben eine Leiche geschaffen und die vielen Hände in Gummihandschuhen genau beobachtet.

    Das Prinzip der Offenheit / Nähe


    O, OCP, Open / Closed-Prinzip
    " Software-Entities ... müssen für die Erweiterung offen, aber für die Änderung geschlossen sein "

    Wenn das vorherige Prinzip irgendwie auf die Möglichkeit einer realen Anwendung gebracht werden kann, gibt es keine Optionen. Im Limit können Sie Ihren Code nicht sofort ändern, nachdem Sie Ihre Hände über die Tastatur gehoben haben.

    Vielleicht tröstet es Sie, dass Sie den Code ändern können: vor dem Testen, vor dem Übertragen in die Produktion, vor der Veröffentlichung der Version, bis ... (einige auswählen, unterstreichen oder eigene hinzufügen). Es spielt keine Rolle, Sie werden immer dieses "DO" haben. Schwacher Trost in Systemen, deren Lebensdauer nicht stunden- und wochenlang, sondern jahrelang anhält.

    Haben Sie jemals beobachtet, dass sich in der Natur etwas „vorher“ entwickelt? Der Baum wächst nicht genau zwei Meter, immer etwas höher, etwas tiefer. Und bis es abgeholzt ist, wächst es, einige Zweige trocknen aus, andere entwickeln sich. Das einzige, was in der realen Welt nicht erreichbar ist, ist Konstanz .

    Warum weit gehen: C => C ++ => (Java =>) C # und Java => Scala => Kotlin versucht, dieses Problem zu umgehen und nicht zu lösen. Nach diesem Prinzip werden Sie sich früher oder später hinsetzen und alles neu schreiben, es sei denn, zu diesem Zeitpunkt war Ihr Projekt bereits so schlecht, dass Sie es begraben haben.

    Dieses Prinzip setzt Ihrem Projekt zu Beginn ein abschließendes und fettes Kreuz. Mit ihm erschaffen Sie Frankenstein in der Hoffnung, dass niemand den Leichengeruch bemerkt.

    Die restlichen Prinzipien können für den nächsten Artikel übernommen werden (es sei denn, dies folgt natürlich) ...

    Die Schlussfolgerung ist prosaisch. Moderne Entwicklung ist wie das Schaffen von Sackgassen in der Kunstkamera und deren gemeinsame Vorbereitung bei der Erstellung, Umsetzung und Unterstützung von Projekten. Daher ist in vielen Lebenszyklen von Methoden häufig nicht einmal das Konzept der "Entsorgung" (Fertigstellung, Stilllegung) vorhanden. Oder sie erhalten ein paar Absätze (Schauen Sie sich zum Beispiel die Operationsbibliotheken an, wenn sie wirklich versuchen, sie am Leben zu lassen).

    Warum über das schreiben, was bereits geschaffen wurde und so sorgfältig versteckt, desodoriert und vorbereitet ist? Wenn jeder der Teilnehmer an der Aktion, an wen früher, an wen später, wird klar, dass "Zeit".

    Hoffnung?


    Aber was ist zu tun, fragst du? (Es sei denn, Sie haben natürlich gelesen und nachgedacht). Das Erstellen von "Mutanten" ist ebenfalls keine Option. Wenn etwas sein Verhalten unvorhersehbar und unnötig ändert, stirbt es normalerweise selbst oder wird gelöscht.

    Die Antwort ist ganz einfach: Schauen Sie sich um, kriechen Sie unter den Haufen von Prinzipien und Methoden hervor. Hören Sie sich den Rat an, aber überlegen Sie, wann Sie ihn befolgen und wann Sie ihn brechen sollten. Befolgen Sie den Vertrag, den Sie brauchen, aber nicht mehr. Letztendlich interessiert es niemanden, was Ihr Code macht, wenn er korrekt und wie erwartet funktioniert.

    Wenn jemand Ihr „Merkmal“ umgangen hat, ist es besser, ihn diese unnötig gewordene Krücke entfernen zu lassen, als dass Sie die fehlerhafte Entscheidung weiterhin beharrlich unterstützen. (Eine gute Analogie zu einem Patienten, der nach dem Entfernen des Gipsverbandes keine unnötigen Krücken zurücklassen möchte, ist er an diese gewöhnt. Es ist praktisch und sein Bein schmerzt beim Gehen.)

    Wenn jemand (Klient, Manager, PM) an Ort und Stelle bleiben möchte, holen Sie ihn version und lass es zerlegen, hilf ihm manchmal (vor allem wenn er zahlt). Aber zögern Sie nicht, eine bessere Lösung zu zeigen. Geben Sie der Person die Möglichkeit, ihre Meinung zu ändern.

    Gehen Sie nicht in einen endlosen Kreislauf. Es macht keinen Sinn, den Mangel an Ergebnis durch den Wunsch zu rechtfertigen, das Ewige zu schaffen, das ist unmöglich. Erstellen Sie jetzt kleine, aber notwendige und "lebende".

    Passen Sie auf, wenn Sie das nächste Mal trainieren, anweisen und die Erfüllung der zugewiesenen Aufgaben fordern. Schauen Sie, wenn Sie einem "Verrückten" in die Augen schauen, der die Leiche in vollem Vertrauen "zerlegt", damit die "Welt" rettet.

    Kreieren Sie keine Leichen. Entwickle dich oder stirb.

    Jetzt auch beliebt: