Wie gestaltet man Objekte?

Question

Es gibt also viele Möglichkeiten, Objekte zu strukturieren (ich spreche hier von OOP). Für die Frage werde ich das klassische "Auto"-Beispiel von OOP verwenden. Woher weiß ich im Grunde, wann ich das Auto zu einem Objekt oder das Rad eines Autos zu einem Objekt machen soll, wenn beide Programmstrukturen das Ziel erreichen würden?

Wie klassifiziere und kategorisiere ich die Teile eines Objekts, um festzustellen, ob sie besser als einfache Attribute oder Variablen eines Objekts geeignet sind, oder ob sie wirklich selbst ein Objekt sein müssen?

Answer 1

Zunächst einmal müssen Sie erkennen, dass OOAD ("Object-oriented analysis and design") ein Werkzeug und kein Mittel zum Zweck ist. Das Ergebnis dieses Prozesses ist ein Modell und keine echte Darstellung dessen, was man modelliert. Dieses Modell geht von bestimmten Annahmen aus. Der Zweck dieses Modells ist es, ein Problem zu lösen, das Sie haben.

Woher wissen Sie also, wie man Objekte gestaltet? Woher weiß man, ob man es richtig gemacht hat? Durch das Endergebnis: Hat es Ihr Problem gelöst?

In einigen Modellen kann die Anzahl der Fahrzeuge einfach eine ganze Zahl sein, z. B. die Anzahl der Fahrzeuge, die eine Kreuzung in einem Verkehrsmodell passieren. In einem solchen Modell interessiert man sich selten für die Marke, das Modell oder die Bauart der Autos, sondern nur für die Anzahl. Sie könnten sich für die Art des Fahrzeugs interessieren, z. B. ob es sich um einen Lkw oder einen Pkw handelt. Modellieren Sie das als ein Fahrzeug-Objekt mit dem Typ Car oder Truck? Oder nur getrennte carCount- und truckCount-Tabellen?

Die kurze Antwort lautet: je nachdem, was am besten funktioniert.

Der normale Test, ob etwas ein Objekt ist oder nicht, besteht darin, ob es ein Verhalten hat. Denken Sie daran, dass Objekte letztendlich Daten + Verhalten sind.

Man könnte also sagen, dass Autos den folgenden Zustand haben:

• der Räder;

• Höhe der Aufhängung;

• Antrieb links oder rechts;

• Farbe;

• Breite;

• Gewicht;

• Länge;

• Höhe;

• von Türen;

• Ob er ein Schiebedach hat;

• Ob es eine Stereoanlage, einen CD-Spieler, einen MP3-Spieler und/oder ein Satellitennavigationssystem hat;

• Größe des Benzintanks;

• Anzahl der Zylinder;

• von Turbolader und/oder Kraftstoffeinspritzung;

• Maximales Drehmoment;

• Maximale Bremsleistung;

• und so weiter.

Wahrscheinlich interessiert Sie nur ein kleiner Teil davon: Wählen Sie das aus, was relevant ist. In einem Rennspiel könnte man mehr Details über die Räder erfahren, z.B. wie heiß sie sind, wie abgenutzt, die Breite und die Art des Profils und so weiter. In einem solchen Fall könnte man sagen, dass ein Rad-Objekt eine Sammlung all dieser Zustände ist (aber wenig Verhalten), weil ein Auto eine Reihe von Rädern hat und die Räder austauschbar sind.

Damit sind wir beim zweiten Punkt über Objekte: Ein Objekt kann aufgrund einer Beziehung existieren, so dass das Objekt einen vollständigen Datensatz darstellt. Ein Rad kann also ein Profil, eine Breite, eine Temperatur und so weiter haben. Man kann das nicht aufteilen und sagen, ein Auto hat ein Profil, aber keine Radbreite, also macht es Sinn, dass ein Rad ein Objekt ist, da ein Rad in seiner Gesamtheit austauschbar ist.

Aber noch einmal: Ist das für das, was wir tun, sinnvoll? Das ist die entscheidende Frage.

Answer 2

Fangen Sie nicht damit an, die Dinge zu klassifizieren - Es scheint, als ob die Leute zu eifrig mit dem Aufbau von Vererbungshierarchien beginnen.

eine Liste spezifischer, konkreter Szenarien aufschreiben - was Ihre Anwendung tun wird, Schritt für Schritt. Ein Objektmodell ist nur dann nützlich, wenn es das tut, was Sie von ihm erwarten - arbeiten Sie sich also von den Szenarien zurück, um zu sehen, welche gemeinsamen Objekte und Verhaltensweisen Sie aus jedem einzelnen herausschütteln können.

die "Rollen" in Ihren Szenarien zu identifizieren - nicht notwendigerweise tatsächliche Klassennamen - nur vage "Rollen", die auftauchen, wenn Sie konkrete Szenarien durchdenken, wie Ihre Software funktionieren wird. Diese Rollen können später zu Klassen, Schnittstellen, abstrakten Klassen werden - was auch immer Sie brauchen - am Anfang sind sie nur Platzhalter für eine bestimmte Art von Arbeit.

Erarbeiten Sie, was jede Rolle "tut". Der Schlüssel dazu ist eine Reihe von benannten Rollen, die festlegen, was die Objekte tun sollen. Bei Thins geht es darum, eine Reihe von Dingen herauszudestillieren, die jede Rolle tun kann - sie könnte die ganze Sache erledigen oder eine Reihe anderer Objekte zusammenstellen, um die Arbeit zu erledigen, oder sie könnte die Arbeit koordinieren... das hängt von Ihren Szenarien ab.

Das Wichtigste bei OOD/OOP ist: OBJECTS DO THINGS - nicht das, was in ihnen steckt - was sie tun.

Denken Sie nicht zu früh an das Erbe - weil es Sie in überkomplizierte Hierarchien verstrickt und Sie dazu bringt, in Begriffen der SQL-orientierten Programmierung statt der objektorientierten Programmierung zu denken. Vererbung ist nur eine Möglichkeit, gemeinsamen Code gemeinsam zu nutzen. Es gibt viele andere Möglichkeiten - Delegation, Mixins, prototypbasierte Programmierung...

Hier sind einige Leitlinien, die mir dabei helfen sollen:

Was sollte auf einer Checkliste stehen, die jemandem hilft, gute OO-Software zu entwickeln?

Answer 3

Hier gibt es einige gute Antworten, aber möglicherweise mehr, als Sie gesucht haben. Um kurz auf Ihre spezifischen Fragen einzugehen:

• Woher weiß ich, wann ich das Auto zu einem Objekt oder das Rad eines Autos zu einem Objekt machen soll, wenn beide Programmstrukturen das Ziel erreichen würden?

  Wenn Sie eine Instanz von einer anderen unterscheiden müssen, dann brauchen Sie ein Objekt. Das wichtigste Unterscheidungsmerkmal eines Objekts ist: Es hat eine Identität.

  Erweitert man diese Antwort ein wenig auf Klassen, so braucht man eine neue Klasse, wenn das Verhalten und/oder die Eigenschaften von zwei ähnlichen Objekten voneinander abweichen.

  Wenn Sie also eine Verkehrssimulation modellieren, bei der die Räder gezählt werden, kann eine Fahrzeugklasse mit der Eigenschaft NumberOfWheels ausreichend sein. Wenn Sie eine Rennsimulation mit detaillierter Fahrbahn- und Raddrehmomentphysik modellieren, muss wahrscheinlich jedes Rad ein eigenständiges Objekt sein.

• Wie klassifiziere und kategorisiere ich die Teile eines Objekts, um festzustellen, ob sie besser als einfache Attribute oder Variablen eines Objekts geeignet sind, oder ob sie wirklich selbst ein Objekt sein müssen?

  Die wichtigsten Unterscheidungen sind Identität und Verhalten. Ein Teil mit eindeutiger Existenz ist ein Objekt. Ein Teil mit eigenständigem Verhalten erfordert eine eigene Klasse.

  Wenn Sie beispielsweise eine sehr einfache Autounfallsimulation erstellen, können NumberOfPassengers und DamageResistance als Eigenschaften einer generischen Fahrzeugklasse ausreichen. Dies würde ausreichen, um Ihnen mitzuteilen, ob das Auto einen Totalschaden erlitten hat und die Insassen überlebt haben. Wenn Ihre Simulation sehr viel detaillierter ist, wenn Sie z. B. wissen wollen, wie weit jeder Insasse bei einem Frontalzusammenstoß geschleudert wurde, dann benötigen Sie eine Klasse Passenger und verschiedene Passenger-Objekte in jedem Vehicle.

Answer 4

Ich mag Wirfs-Brock's Verantwortungsbewusstes Design (RDD) und empfehlen auch dieses aktualisierte (kostenlose) Papier Verantwortungsgesteuerte Modellierung Ansatz von Alistair Cockburn.

In über 15 Jahren OO-Entwicklung habe ich immer dann, wenn ich das Gefühl hatte, mich in einer Software-Architektur zu verirren, auf die RDD-Grundlagen zurückgegriffen, um zu klären, was die Software eigentlich tun soll und wie.

Wenn Sie einen testgesteuerten Ansatz mögen, dieser Artikel zeigt, wie man RDD mit Mocking-Objekten und Tests verbindet.

Answer 5

Attribute oder Variablen sind oft "Grundtypen" einer Sprache. Die Frage ist, was man sinnvollerweise abstrahieren kann.

Sie können zum Beispiel eine Wheel zu Deskriptoren, die aus Basistypen wie Ganzzahlen, Fließkommazahlen und Zeichenketten bestehen, die charakteristische Attribute eines beliebigen Rads darstellen: numberOfTreads , diameter , width , recommendedPressure , brand . Diese Attribute können alle mit Basistypen ausgedrückt werden, um eine Wheel Objekt.

Können Sie einige dieser Attribute in einer abstrakteren Anordnung gruppieren, die Sie unabhängig von einer der folgenden Kategorien wiederverwenden können? Wheel ? Ich denke schon. Vielleicht erstellen Sie eine Dimensions Objekt mit den Attributen diameter y width . Dann wird Ihr Wheel hat eine Dimensions Objektinstanz, die mit ihm verbunden ist, statt diameter y width . Aber Sie könnten darüber nachdenken, das zu verwenden Dimensions Objekt mit anderen Objekten, die nicht unbedingt Wheel Instanzen.

Wenn Sie in der Liste nach oben gehen, können Sie eine Car aus Basistypen bestehen, aber auch aus anderen Objekten, wie z. B. Wheel Objekte. Dies ist sinnvoll, da andere motorisierte und nicht motorisierte Fahrzeuge (z. B. ein Bicycle ) enthalten auch Wheel Instanzen.

Abstrahieren Wheel y Dimensions können Sie diese Objekttypen in verschiedenen Kontexten wiederverwenden, die Sie vielleicht zunächst nicht in Betracht ziehen. Das macht Ihr Leben ein wenig einfacher, weil Sie theoretisch weniger Code neu schreiben müssen.

Wenn Sie eine Hierarchie von Objekten erstellen können, die so weit geht, dass das tiefste, unterste Objekt nur aus einigen wenigen Basistypen besteht, ist das wahrscheinlich ein guter Anfang.