Dies ist ein von KI übersetzter Beitrag.
Sprache auswählen
Von durumis AI zusammengefasster Text
- In der Softwareentwicklung ist die Praxis wichtiger als die Theorie, und durch einfache Programme kann man die Bedeutung objektorientierten Designs erkennen.
- Am Beispiel einer Ticketverkaufsanwendung wird erläutert, wie man durch Reduzierung der Abhängigkeiten und Kopplung zwischen Objekten flexiblen Code schreibt, und die Unterschiede zwischen prozeduraler und objektorientierter Programmierung werden verglichen.
- Objektorientiertes Design führt zu veränderbarem Code, und Objekte sind selbstverwaltende Entitäten, die für ihre eigenen Daten verantwortlich sind. Die Abhängigkeiten zwischen kooperierenden Objekten müssen angemessen verwaltet werden.
Einführung
Robert L. Glass argumentierte, dass die Praxis der Theorie vorangeht. Besonders in der Softwareentwicklung ist die Praxis ein typisches Gebiet, in dem die Praxis der Theorie vorausgeht. Entwickler lernen am meisten, wenn sie sich mit konkretem Code beschäftigen und ihre Hände schmutzig machen. Daher wollen wir die Theorie und Konzepte für einen Moment zurücklassen und uns ein einfaches Programm ansehen.
Implementieren einer Ticketverkaufsanwendung
- Wir planen eine kleine Veranstaltung zur Werbung für ein kleines Theater.
- Veranstaltungsdetails: Verlosung von kostenlosen Eintrittskarten für ausgewählte Zuschauer
- Gewonnene Zuschauer müssen von den Verlierern getrennt werden.
- Gewonnene Zuschauer: Eintauschen der Eintrittskarte gegen ein Ticket
- Verlierer: Kauf des Tickets mit Geld
Was ist das Problem?
Robert Martin beschreibt drei Funktionen, die ein Softwaremodul (unabhängig von der Größe, ein beliebiges Element, aus dem ein Programm besteht, wie z. B. eine Klasse, ein Paket oder eine Bibliothek) haben sollte.
- Funktioniert während der Ausführung einwandfrei.
- Existiert für Änderungen.
- Änderungen sollten mit minimalem Aufwand möglich sein.
- Kommuniziert mit Menschen, die den Code lesen.
- Entwickler sollten den Code leicht lesen und verstehen können.
Die obige Ticketverkaufsanwendung erfüllt die erste Einschränkung, dass sie korrekt ausgeführt wird, aber die Ziele Änderungsfreundlichkeit und Kommunikation sind nicht erfüllt.
Code, der die Erwartungen nicht erfüllt
Betrachten wir die Gründe, warum das Ziel der Kommunikation nicht erfüllt wird.
- Die Aufgabe der enter() Methode der Klasse Theater
- Das Theater überprüft die Tasche des Zuschauers, um zu sehen, ob sich eine Einladung darin befindet.
- Wenn sich eine Einladung in der Tasche befindet, wird der Verkäufer angewiesen, das Ticket, das im Kartenschalter aufbewahrt wird, in die Tasche des Zuschauers zu legen.
- Wenn sich keine Einladung in der Tasche befindet, wird der Verkäufer angewiesen, den Ticketpreis aus der Tasche des Zuschauers zu nehmen, das Ticket zu kaufen und das Ticket in die Tasche zu legen.
- Aus Sicht des Zuschauers muss er zusehen, wie das Theater als Dritter willkürlich in seine Tasche greift, Geld nimmt und ein Ticket hineingibt.
- Aus Sicht des Verkäufers muss er zusehen, wie das Theater als Dritter ohne Erlaubnis den Ticketpreis im Kartenschaltermanipuliert.
- Verständlicher Code ist Code, dessen Verhalten nicht stark von unseren Erwartungen abweicht. Das Theater in unseremBeispiel weicht jedoch von unseren Erwartungen ab.
- Der Zuschauer sollte das Geld aus seiner eigenen Tasche nehmen und es an den Verkäufer zahlen, um ein Ticket zu erhalten.
- Der Verkäufer sollte das Ticket direkt aus dem Kartenschalter nehmen und es an den Zuschauer übergeben und das Geld vom Zuschauer entgegennehmen, um es im Kartenschalter aufzubewahren.
- Außerdem müssen Sie sich an viele Details erinnern, um die enter() Methode zu verstehen.
- Audience hat eine Bag.
- Bag enthält Bargeld und Tickets.
- TicketSeller verkauft Tickets im TicketOffice. Im TicketOffice werden Geld und Tickets aufbewahrt.
Code, der anfällig für Änderungen ist
Die enter() Methode geht von zwei Bedingungen aus.
- Der Zuschauer trägt immer eine Tasche mit sich, um Bargeld und Einladungen aufzubewahren.
- Der Verkäufer verkauft Tickets nur am Kartenschalter.
Wie wäre es mit folgenden Situationen?
- Der Zuschauer hat möglicherweise keine Tasche dabei.
- Der Zuschauer könnte eine Kreditkarte anstelle von Bargeld verwenden.
- Der Verkäufer könnte Tickets außerhalb des Kartenschalters verkaufen.
Um beispielsweise die erste Anforderung zu erfüllen, müssen wir das Bag-Objekt der Audience entfernen und die enter()- Methode der Klasse Theater anpassen. Dies liegt daran, dass die Klasse Theater zu sehr von der Tatsache abhängt, dass der Zuschauer eine Tasche trägt und der Verkäufer Tickets nur am Kartenschalter verkauft. Wenn sich eines dieser Details ändert, müssen sowohl die entsprechende Klasse als auch die abhängige Klasse (z. B. Theater) geändert werden.
Dies ist ein Problem, das mit der Abhängigkeit zwischen Objekten zusammenhängt, und die Abhängigkeit impliziert den Einfluss auf Änderungen. Da das objektorientierte Design jedoch darauf abzielt, eine Gemeinschaft von Objekten zu erzeugen, die sich gegenseitig abhängen und zusammenarbeiten, sollten wir Abhängigkeiten nicht einfach entfernen, sondern dieminimal notwendige Abhängigkeitenbeibehalten und unnötige Abhängigkeiten entfernen.
Wenn es zu viele Abhängigkeiten zwischen Objekten gibt, spricht man von hoher Kopplung. Je höher die Kopplung zwischen zwei Objekten ist, desto höher ist die Wahrscheinlichkeit, dass sie zusammen geändert werden müssen. Daher ist das Ziel des Designs, die Kopplung zwischen Objekten zu verringern, um ein Design zu erstellen, das leicht zu ändern ist.
Das Design verbessern
Das Theater muss nicht wissen, dass der Zuschauer eine Tasche dabei hat und der Verkäufer Tickets am Kartenschalter verkauft. Das Theater möchte nur, dass der Zuschauer ins Theater kommt. Daher müssen wir den Zuschauer dazu bringen, das Geld und die Einladung in seiner Tasche selbst zu verwalten, und den Verkäufer dazu bringen, die Tickets und den Preis am Kartenschalter selbst zu verwalten, so dass sie selbständige Einheiten werden.
Die Autonomie erhöhen
Ein Objekt, das nur eng miteinander verbundene Aufgaben ausführt und nicht verwandte Aufgaben an andere Objekte delegiert, wird als hohes Kohäsionsniveau bezeichnet. Wenn Sie selbständige Objekte erstellen, die ihre eigenen Daten selbst verwalten, können Sie die Kopplung reduzieren und die Kohäsion erhöhen.
Prozedurale und objektorientierte Programmierung
- Prozedurale Programmierung
- Die enter() Methode von Theater ist ein Prozess, während Audience, TicketSeller, Bag und TicketOffice Daten sind.
- Die Platzierung von Prozessen und Daten in separaten Modulen wird als prozedurale Programmierung bezeichnet.
- Es gibt viel Code, der unserer Intuition widerspricht. (z. B. Der Zuschauer verwaltet sein Geld und seine Einladungen selbst.)
- Es ist schwierig, den Einfluss von Datenänderungen zu begrenzen.
- Die Verantwortung wird zentral verwaltet. (Theater verwaltet alles.)
- Objektorientierte Programmierung
- Die Platzierung von Daten und Prozessen im selben Modul wird als objektorientierte Programmierung bezeichnet.
- Wir können Code schreiben, der unserer Intuition entspricht.
- Der Einfluss von Datenänderungen kann durch Kapselung effektiv eingeschränkt werden.
- Jedes Objekt ist für sich selbst verantwortlich.
Es kann noch verbessert werden.
- Die Bag-Klasse der Audience-Klasse ist immer noch ein passives Wesen, das von der Audience-Klasse herumgeschleppt wird, daher muss die Bag-Klasse in ein selbständiges Objekt umgewandelt werden.
- Auch das TicketOffice der TicketSeller-Klasse wird von TicketSeller willkürlich verwaltet. TicketOffice muss in ein selbstständiges Objekt umgewandelt werden.
- Allerdings führt die Änderung zu einer zusätzlichen Kopplung zwischen TicketOffice und Audience.
- Wie bei solchen Designs müssen wir sorgfältig die Vor- und Nachteile abwägen. In diesem Fall könnten wir vereinbaren, TicketOffice zu einem einigermaßen passiven Objekt zu machen, um die Kopplung zu Audience zu reduzieren.
Ja, das ist eine Lüge!
- Auch wenn etwas in der Realität passiv ist, wird es in der objektorientierten Welt zu einem aktiven und selbständigen Wesen.
- Es ist ratsam, die Personifikation zu verwenden, um passive Objekte als etwas zu betrachten, das lacht, spricht und sich ärgert.
Objektorientiertes Design
Warum ist Design notwendig?
- Design ist die Anordnung von Code.
- Gutes Design ist in der Lage, die heute benötigten Funktionen vollständig zu erfüllen und gleichzeitig zukünftige Änderungen reibungslos zu bewältigen.
Objektorientiertes Design
- Änderungsfähiger Code ist leicht verständlicher Code.
- Das objektorientierte Paradigma hilft uns, Code so zu schreiben, wie wir die Welt sehen.
- Objekte sind selbständige Wesen, die für ihre eigenen Daten verantwortlich sind.
- Ein großartiges objektorientiertes Design ist ein Design, das die Abhängigkeiten zwischen zusammenarbeitenden Objekten angemessen verwaltet.
Quellen
- Objekte
