FEST, was sind die 5 Prinzipien der objektorientierten Programmierung

Feste feste geometrische Figuren
Ausbildung
1

SOLID ist ein Akronym, das sich auf die fünf Prinzipien des objektorientierten Designs (OOD oder OOP) bezieht. Mit diesen Richtlinien können Entwickler Software erstellen, die einfach zu verwalten, zu warten und zu erweitern ist. Wenn Sie diese Konzepte verstehen, werden Sie zu einem besseren Entwickler und können Probleme bei der Softwareverwaltung vermeiden. Was bedeutet es, ein guter Programmierer zu sein?

Jeder, der Erfahrung in der Softwareprogrammierung hat, beurteilt den von anderen geschriebenen Software-Code anhand von Beurteilungsparametern, die auf seinem Karriereweg basieren.

Im Laufe meiner beruflichen Laufbahn habe ich viele Entwickler gekannt und Tausende von Codezeilen gesehen. Wenn ich die Fähigkeiten eines Entwicklers bewerten muss, betrachte ich hauptsächlich zwei Faktoren:

  • Einfachheit beim Lesen des Codes;
  • Wie wahrscheinlich es ist, dass ihr Code im Laufe der Zeit funktioniert und sich weiterentwickelt.

Glücklicherweise gibt es einige Grundlagen oder Prinzipien, die es einfach machen, besser zu codieren.

das Akronym SOLID steht für:
S: Prinzip der Einzelverantwortung
O: offen-geschlossen-Prinzip
L: Liskov-Substitutionsprinzip
I: Prinzip der Schnittstellentrennung
D: Prinzip der Inversion von Abhängigkeiten

Beginnen wir mit dem ersten SOLID-Prinzip, nämlich dem

Prinzip der Einzelverantwortung

Eine Klasse (oder ein Modul) sollte nur einen Grund haben, sich zu ändern, sich weiterzuentwickeln.

Das Konzept selbst ist sehr einfach, aber um diese Einfachheit zu erreichen, kann der Implementierungspfad sehr kompliziert sein. Eine Klasse sollte nur einen Grund haben, sich zu ändern.

Aber warum 

Warum ist es so wichtig, nur einen Grund zur Änderung zu haben?

Wenn es beispielsweise zwei verschiedene Gründe für eine Änderung gibt, ist es denkbar, dass zwei verschiedene Teams aus zwei verschiedenen Gründen an demselben Code arbeiten. Jeder muss seine eigene Lösung implementieren, was im Fall einer kompilierten Sprache (wie C ++, C # oder Java) zu Modulen führen kann, die mit anderen Teams oder anderen Teilen der Anwendung nicht kompatibel sind.

Ein weiteres Beispiel: Wenn Sie eine interpretierte Sprache verwenden, müssen Sie möglicherweise dieselbe Klasse oder dasselbe Modul aus verschiedenen Gründen erneut testen. Dies bedeutet mehr Arbeit, Zeit und Aufwand für die Qualitätskontrolle.

Das Identifizieren der einzigen Funktion, die eine Klasse oder ein Modul haben sollte, ist viel komplexer als das bloße Betrachten einer Checkliste zum Ausführen von Tests. 

Aber versuchen wir, unter einem weniger technischen Gesichtspunkt zu denken, dh versuchen wir, den Benutzer unserer Klasse oder unseres Moduls zu analysieren, dh wer es verwenden wird. Ein grundlegender Aspekt, den wir immer berücksichtigen müssen, ist die Tatsache, dass die Benutzer der von uns entwickelten Anwendung oder des von uns entwickelten Systems, die von einem bestimmten Modul bedient werden, diejenigen sind, die Änderungen daran anfordern. Diejenigen, die bedient werden, werden gebeten, die Klasse oder das Modul zu ändern. 

Einige Beispiele für Module und ihre Verwendung:

  • Wartungsmodul: Der Benutzer besteht aus Datenbankadministratoren und Softwarearchitekten.
  • Berichtsmodul: Der Benutzer besteht aus Büroangestellten, Buchhaltern und der Produktion
  • Zahlungsberechnungsmodul für ein Lohn- und Gehaltsabrechnungssystem: Benutzer können Anwälte, Manager und Buchhalter sein.
  • Textsuchmodul für ein Bibliotheksverwaltungssystem: Der Benutzer kann vom Bibliothekar oder von den Besuchern und Kunden der Bibliothek selbst vertreten werden.

Wenn der erste Schritt darin besteht, nach den Akteuren oder dem Akteur zu suchen, der die Rolle des Gesprächspartners mit dem Modul hat, kann es schwierig sein, Personen mit allen Rollen zu verknüpfen. In einem kleinen Unternehmen kann eine Person mehrere Rollen spielen, während in einem großen Unternehmen mehrere Personen eine einzige Rolle spielen können. 

Es erscheint vernünftiger, Rollen zu identifizieren, als Personen oder Benutzer.

so:

  • Der Benutzer des Softwaresystems definiert die Gründe für die Änderung.
  • Eine Verantwortung ist eine Familie von Funktionen, die die Bedürfnisse eines bestimmten Akteurs, dh des Benutzers des Systems, erfüllen.
  • Für die Akteure wird der Benutzer zu einer Quelle der Veränderung für die Familie der Funktionen, die die Bedürfnisse des Benutzers befriedigen müssen.
  • Die Entwicklung der Benutzeranforderungen leitet die Entwicklung der Funktionalität.

FESTE Prinzipien

Sehen wir uns einige Beispiele an

Angenommen, wir haben eine Buchklasse, die das Konzept eines Buches und seine Funktionalität zusammenfasst.

Klassenbuch {

    Funktion getTitle () {

        gib "Ein großartiges Buch" zurück;

    }

    Funktion getAuthor () {

        Rückkehr "Alessandro Baricco";

    }

    Funktion nextpage () {

        // Nächste Seite

    }

    Funktion printCurrentPage () {

        Echo "Inhalt der aktuellen Seite";

    }

}

Dies ist eine ganz normale Klasse. Wir haben ein Buch, und die Klasse kann uns den Titel geben, kann uns den Autor geben und kann weitermachen. Schließlich kann auch die aktuelle Seite auf dem Bildschirm gedruckt werden. 

Es gibt jedoch ein kleines Problem. 

Wer könnten sie sein, wenn sie an die Akteure denken, die an der Verwaltung des Buchobjekts beteiligt sind? 

Wir können uns hier leicht zwei verschiedene Schauspieler vorstellen: Buchverwaltung (Kommen il Bibliothekar) und Datenübermittlungsmechanismus (Zum Beispiel, wie wir dem Benutzer Inhalte bereitstellen möchten: Bildschirm, grafische Benutzeroberfläche, Nur-Text-Benutzeroberfläche, möglicherweise Drucken). 

Wir haben daher zwei sehr unterschiedliche Akteure, die mit der Klasse interagieren.

Kurz gesagt, diese Klasse macht eine Mischung aus:

  • Geschäftslogik mit 
  • die Präsentation 

Dies kann ein Problem sein, da es gegen das Single-Liability-Prinzip (SRP) verstößt. 

Wie können wir uns ändern, wie können wir diesen Kodex verbessern, um das Prinzip der Einzelverantwortung zu respektieren?

Sehen Sie sich den folgenden Code an:

Klassenbuch {

    Funktion getTitle () {

        Rückgabe „Oceano Mare“;

    }

    Funktion getAuthor () {

        Rückkehr "Alessandro Baricco";

    }

    Funktion umblättern () {

        // Nächste Seite

    }

    Funktion getCurrentPage () {

        Echo "Inhalt der aktuellen Seite";

    }

}

Schnittstelle Drucker {

    Funktion printPage ($ page);

}

Klasse StampaLibro implementiert Drucker {

    Funktion printPages ($ page) {

        echo $ page;

    }

}

 

Klasse HtmlPrinter implementiert Printer {

    Funktion printPages ($ page) {

        Echo ' '. $ page. ' ';

    }

}

Dieses sehr einfache Beispiel zeigt, wie die Präsentation von der Geschäftslogik getrennt werden kann. In Übereinstimmung mit dem SRP bietet es große Vorteile für die Flexibilität unseres Projekts.

Schauen wir uns ein anderes Beispiel an:

Ein ähnliches Beispiel wie oben ist, wenn ein Objekt sich selbst speichern und aus der Präsentation abrufen kann.

Klassenbuch {

    Funktion getTitle () {

        Rückgabe „Oceano Mare“;

    }

    Funktion getAuthor () {

        Rückkehr "Alessandro Baricco";

    }

    Funktion umblättern () {

        // Nächste Seite

    }

    Funktion getCurrentPage () {

        "Inhalt der aktuellen Seite" zurückgeben;

    }

    Funktion save () {

        $ filename = '/ documents /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ filename, serialize ($ this));

    }

}

Nach wie vor können wir auch hier verschiedene Akteure wie identifizieren Buchverwaltung (Kommen il Bibliothekar) und Beharrlichkeit. Wann immer wir die Art und Weise ändern möchten, wie wir von Seite zu Seite wechseln, müssen wir diese Klasse ändern. Wir können mehrere Gründe für Änderungen haben.

Klassenbuch {

    Funktion getTitle () {

        Rückgabe „Oceano Mare“;

    }

    Funktion getAuthor () {

        Rückkehr "Alessandro Baricco";

    }

    Funktion umblättern () {

        // Nächste Seite

    }

    Funktion getCurrentPage () {

        "Inhalt der aktuellen Seite" zurückgeben;

    }

}

Klasse SimpleFilePersistence {

    Funktion speichern (Buch $ Buch) {

        $ filename = '/ documents /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ filename, serialize ($ book));

    }

}

Wenn Sie die Persistenzoperation in eine andere Klasse verschieben, werden die Verantwortlichkeiten klar voneinander getrennt, und es steht uns frei, Persistenzmethoden auszutauschen, ohne unsere Buchklasse zu beeinträchtigen. Zum Beispiel wäre die Implementierung einer DatabasePersistence-Klasse trivial, und unsere Geschäftslogik, die auf Buchoperationen basiert, wird sich nicht ändern.

Lesen Sie weiter das zweite Prinzip Offen / Geschlossen ->

1 Kommentar

Hinterlassen Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Liskov-Prinzip
Ausbildung
Prinzip der Liskov-Substitution, drittes SOLID-Prinzip

Untergeordnete Klassen sollten die Typdefinitionen der übergeordneten Klasse niemals beeinflussen oder ändern. Das Konzept dieses Prinzips wurde von Barbara Liskov in einer Keynote der Konferenz von 1987 vorgestellt und 1994 zusammen mit Jannette Wing in einem Artikel veröffentlicht. Ihre ursprüngliche Definition…

Google Marketing Trends
Ausbildung
So verwenden Sie Google Trends für Echtzeit-Marketing

Eine der größten Schwierigkeiten für Unternehmen im Jahr 2020 bestand darin, zu verstehen, in welchen Produktsektoren sie ihr Geschäft diversifizieren sollten: Tatsächlich haben die meisten Industriesektoren starke Auswirkungen, die es Unternehmen fast unmöglich machen, in sie einzudringen, insbesondere als neuer Akteur. Sehr wenige verarbeitende Sektoren ...

Business-Intelligence-Strategie
Methods
Strategien für erfolgreiche Business Intelligence

Der Aufbau einer erfolgreichen Strategie für Ihre Business Intelligence beginnt mit einer korrekten Vision der Ziele. Wir sehen unten einige grundlegende Punkte. Einschätzung der aktuellen Situation Es wäre ein schwerwiegender Fehler, diesen Aspekt zu unterschätzen. Um die aktuelle Situation zu bewerten, müssen Prozesse, Strukturen ...