OOP: Wo kann ich Abstraktion stoppen?

1. YAGNI (Sie brauchen es nicht) Erstellen Sie keine Abstraktionen, die Sie nicht sofort oder aus einem vernünftigen Grund sehen. Auf diese Weise haben Sie eine einfache Sache, die komplexer werden kann, anstelle von komplizierten Dingen, die Sie anstreben würden, einfacher zu machen, aber zu verlieren.
2. Stellen Sie sicher, dass die Abstraktionen sinnvoll sind. Wenn sie zu weit von der Realität entfernt sind, zu schwer zu rechtfertigen ... vergiss es.
3. Lassen Sie die Lösung sich natürlich anfühlen. Arbeite daran, bis es funktioniert. Dann sollte die Lösung für eine unbekannte Person so offensichtlich erscheinen, dass er schreit "Wie hättest du es anders machen können?".
4. Versuchen Sie nicht, die Zukunft vorherzusagen. Sie können nicht. Wenn Sie versuchen, alle 10 möglichen Fälle abzudecken, werden Sie bald den 11. und mehr entdecken, und es wird schwieriger sein, es wegen der vorherigen 10 zu implementieren, die in der Praxis nicht vorkommen. Machen Sie es einfach und leicht anzupassen. Software muss geändert werden, aber die einfache Anpassung (Agilität) ist oft eine viel bessere Strategie als der Versuch, alle möglichen Fälle im Voraus abzudecken.

Vielleicht sollte diese Frage sein, wo Abstraktion beginnen soll.

Das von Ihnen zitierte Beispiel ist ein klassisches Beispiel dafür, dass zu wenig darüber nachgedacht wird, was die Objekte tatsächlich sind, da sie alle ziemlich gleich sind - und wahrscheinlich besser als ein einzelnes "GameObject" ausgedrückt werden könnten.

Ich vermeide auch die Unterklassierung nach Objekteigenschaften. Für StaticGameObject und DynamicGameObject mag logica erscheinen, aber wahrscheinlich sind sie besser durch Container platziert - dh zwei Listen eine für statische Objekte und eine für dynamische, so dass andere Logik die Aktionen definieren kann und nicht das Objekt selbst für die Steuerung von etwas außerhalb verantwortlich ist Umfang.

Manchmal ist es schwieriger herauszufinden, was von einer Gruppe von Dingen geteilt wird, die Sie in einem Objekt darstellen wollen - aber es lohnt sich.

Ich glaube, dass die Kriterien aus einer klaren Definition der Abstraktion abgeleitet werden können.

Sie beziehen sich auf die Abstraktion innerhalb des objektorientierten Programmierparadigmas, wo Ihnen die drei Prinzipien zur Verfügung stehen: Abstraktion "-" Kapselung '-' Informationen verstecken oder Sichtbarkeit '.

Abstraktion ist der Prozess der Auswahl, welche Attribute des Objekts für Ihr System relevant sind und welche vollständig ignoriert werden müssen.

Das heißt, das Abstraktionslimit betrifft nicht so sehr die Anzahl von Konzepten, die Sie definieren (Spieler, Waffen, Kugeln, ...), sondern was Sie hineinlegen diese Konzepte.

Es ist im Grunde triage , wo Sie nur aus einem Konzept betrachten, was für die Dienste nützlich ist, die Sie definieren müssen.

Also Ein gutes Kriterium, um mit dem Schreiben von normalem Code zu beginnen, könnten die APIs sein , wie das Eclipse-Programm nahelegt: API zuerst .

In der Tat, "Gute APIs erfordern eine Entwurfsiteration", was bedeutet, dass die Liste der Objekte, die Sie in Ihrer Frage erwähnen, verfeinert wird, da die benötigte API selbst verfeinert wird.

Plus, APIs haben wohldefinierte Komponentengrenzen und -abhängigkeiten (wie in "Core-Player - vs. UI - RenderableObject -"), was bedeutet, dass die sehr detaillierte Liste, die Sie erwähnen, nicht als eine lange endlose Liste angesehen werden kann Konzepte, müssen jedoch in einer funktionalen

Da APIs existieren, um die Bedürfnisse von Clients zu erfüllen, werden Sie diese Objekte nur behalten, weil sie für den Client sinnvoll sind. Die anderen Objekte sollten in "internen" Paketen sein und niemals direkt von anderen Teilen Ihrer Anwendung weitergeleitet werden.

In Anbetracht dessen machen @phjr-Ratschläge durchaus Sinn;)