Wie nähern Sie sich dem Klassendesign in OOPs?

Wenn ich versuche, eine OO-Lösung zu entwerfen, verwende ich im Allgemeinen die CRC- Modellierung, bei der ich die Klassennamen (Substantive), ihre Funktionen (Verben) und ihre Zusammenarbeit mit anderen Klassen aufführe.

Dieser Blog hat das Folgende über diesen Nomen-Verb-Ansatz zu sagen

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Meine Frage ist, gibt es eine bessere Modellierungstechnik, um den OO-Ansatz zu verwenden?

Fairerweise hat er dieser Behauptung "In fun" hinzugefügt.

Bis heute neige ich dazu, Systeme mit dem "Nomen und Verb" -Ansatz zu modellieren, aber ich habe im Laufe der Jahre festgestellt, dass TDD uns lehrt, dass dieser Ansatz Ihren Fokus auf das Falsche lenkt. In diesem Sinne hat der Blogger einen Punkt. Ich bin mir jedoch nicht sicher, ob es eher der fehlerhafte Ansatz als die Art und Weise ist, wie unser Geist arbeitet.

Wenn Sie hier eine kleine Herausforderung versuchen möchten, hören Sie auf zu lesen und versuchen Sie, das Monopoly-Spiel in englischer Sprache zu modellieren. Kommen Sie dann hierher zurück.

Ich vermute, die Versuchung wird darin bestehen, sofort die Objekte zu betrachten, mit denen wir viel interagieren - das Brett, die Felder, die Karten, die Würfel, die Teile -, aber hier geht nicht der Großteil der Logik hin. Die meisten dieser Objekte sind völlig dumm. Daten, wenn Sie so wollen.

Sobald Sie jedoch anfangen, Tests zu schreiben, erkennen Sie, welches Objekt bei weitem das wichtigste in einem Spiel ist: die Regeln.

Erinnerst du dich an das kleine Stück Papier, das du einmal gelesen hast, als du das Spiel zum ersten Mal bekommen hast, und mit dem du erst wieder interagierst, wenn es einen Streit gibt? Die Computerversion funktioniert nicht so. Bei jedem Versuch des Spielers konsultiert ein Computer die Regeln und prüft, ob er dies tun darf oder nicht.

Wenn Sie darüber nachdenken, tun Sie dasselbe, aber da das Lesen der papierbasierten Regeln einige Zeit in Anspruch nimmt und Ihr Gehirn über ein vernünftiges Caching-System verfügt, konsultieren Sie die Regeln in Ihrem Kopf. Ein Computer wird es wahrscheinlich genauso einfach finden, die Regeln erneut zu lesen - es sei denn, sie sind in der Datenbank gespeichert. In diesem Fall werden sie möglicherweise auch zwischengespeichert.

Und deshalb ist TDD so beliebt, um tatsächlich Design zu fahren. Weil es dazu neigt, Ihren Denkprozess schnell an die richtigen Stellen zu bringen:

Wenn ich denke, dass ich einige Tests für mein Monopoly-Spiel schreiben werde. Ich könnte auf mein Set schauen und versuchen, die Objekte zu finden. Also haben wir diese Stücke. Ich werde einige Tests für diese schreiben.

Vielleicht habe ich ein MonopolyPiece der Basisklasse und jede Art von Stück leitet sich von diesen ab. Ich werde mit dem DogPiece beginnen. Erster Test ... ahh. Eigentlich gibt es hier keine Logik. Ja, jedes Stück wird anders gezeichnet, daher brauche ich möglicherweise einen DogDrawer, aber während ich das Spiel ausarbeite, möchte ich nur "D" auf den Bildschirm schreiben. Ich werde die Benutzeroberfläche am Ende aufpeppen.

Lassen Sie uns eine tatsächliche Logik zum Testen finden. Es gibt viele dieser Häuser und Hotels, aber sie brauchen keine Tests. Geld, nein. Immobilienkarten, Nr. Und so weiter. Auch wenn die Karte nichts anderes als eine Zustandsmaschine ist, enthält sie keine Logik.

Sie werden schnell feststellen, dass Sie noch drei Dinge in der Hand haben. Die Chance- und Community-Truhenkarten, ein Paar Würfel und ein Regelwerk. Dies sind die wichtigen Teile, die entworfen und getestet werden müssen.

Hast du das kommen sehen, als du die Substantive und Verben ausgeschrieben hast?

Tatsächlich gibt es ein großartiges Beispiel in Robert Martins Agile Principles Patterns and Practices, in denen sie versuchen, eine Bowling Score Card-App mit TDD zu entwickeln und alle möglichen Dinge zu finden, von denen sie glaubten, dass sie offensichtlich keine Klassen wert waren.

Ich habe solche Methoden nie als hilfreich für mich empfunden. Tatsächlich stellte ich fest, dass mich die Verwendung nur noch schlimmer verwirrt. Schauen Sie sich die Kaffeemaschine von Robert C. Martin an . Ich glaube, er verwendet diesen Ansatz auch nicht.

Eine Sache, die mich sofort stört, ist die Lösung, zu der die Person in dem CRC-Artikel kommt, auf den Sie verlinken. Die Zusammenarbeit zwischen Kunde und Auftrag ist nichts, was ich für lohnenswert halte, sowieso nicht so, wie es geschrieben wurde. In diesem Modell ist nichts besonders Interessantes an einem Kunden, der den Klassenstatus verdient. Das einzig Interessante daran, ein "Kunde" zu sein, ist, dass dieser Person eine oder mehrere Bestellungen zugeordnet sind .

Das College-Modell auch. Es gibt viel, was zwischen Student und Professor geteilt werden kann und sollte. Was passiert außerdem, wenn ein Professor eine Klasse besucht, wie es auf dem College-Campus sehr oft kostenlos erlaubt ist?

Ich nehme an, es könnte eine lohnende Übung sein, ein Element im Design-Toolkit. Ich denke nicht, dass dies zumindest die einzige Möglichkeit sein sollte, sich dem Design zu nähern. Ehrlich gesagt finde ich den Ansatz der Gemeinsamkeits- / Variationsanalyse nützlicher. Es scheint mir sehr genau zu modellieren, was wir tun, um Abstraktionen im Alltag zu klassifizieren.

Edit: Lies einfach die Hälfte des zweiten Blogs und ich muss sagen, dass ich ziemlich viel damit einverstanden bin. Ich muss den Rest lesen und sehen, was es in Bezug auf das Lernen bietet.

Meiner Meinung nach sollten Klassen beim Codieren hinzugefügt (und entfernt) werden, um Bedenken zu trennen und Abhängigkeiten zu verringern. Fließende Designmuster sind wahrscheinlich eine gute Wahl, um Möglichkeiten für Refactoring und Vereinfachung zu erkennen.

Nach meiner Erfahrung fallen Klassen im Allgemeinen nicht ordentlich in Substantiv- / Verbkategorien, sondern Sie erhalten eine Mischung aus Substantiv- / Verbklassen zusammen mit verschiedenen Musterklassen (Fabriken, Singletons, Strategiemuster usw.) und anderen Managerklassen das spricht einen Aspekt Ihrer Anwendung an.

Der Schlüssel ist, dass Ihr Ziel darin bestehen sollte, eine Klasse zu betrachten und daraus abzuleiten, was sie tut, und dies zu ändern, indem Sie nur diese Klasse ändern. Je mehr Code für einen Aspekt Ihrer Anwendung auf Klassen verteilt ist, desto schwieriger wird es, ihm zu folgen, ihn zu verwalten und zu erweitern.