Bad OOP, um viele Klassen mit nur 1 oder 2 Methoden zu haben

Sie müssen selbst messen, wenn es zu viel ist. OOP ist eine großartige Möglichkeit, Logik sinnvoll und real zu trennen, aber sie kann auch einen Punkt erreichen, an dem sie die Wartbarkeit negativ beeinflusst. An diesem Punkt wird sie falsch angewendet.

Denken Sie darüber nach, wohin die Anwendung geht. Wird es immer eine kleine App sein? Wenn dies der Fall ist, müssen Sie nicht viele sehr allgemeine Schnittstellen erstellen. Versuchen Sie, sie zu kombinieren, und wenn nur eine Klasse die Schnittstelle implementiert, können Sie die Schnittstelle möglicherweise vollständig entfernen.

Wenn Sie davon ausgehen, dass Ihre Anwendung substanziell wachsen wird, könnten die Schnittstellen Ihnen in Zukunft tatsächlich dabei helfen, Funktionen zu pflegen und hinzuzufügen. Wenn Sie zum Beispiel eine Anwendung zur Verwaltung einer Fahrzeugparzelle mit nur Parkplätzen für Autos erstellt haben, möchten Sie möglicherweise eine generische Automobilschnittstelle erstellen, wenn Sie Wachstum für verschiedene Fahrzeugtypen erwarten (z. B. Motorräder nehmen nur eine halbe Parklücke ein). Das heißt, Sie sollten nicht versuchen, jede denkbare Änderung der Anforderungen zu Beginn eines Projekts zu erfassen und den Code zu abstrakt zu machen. Wenn Sie das Risiko einer Änderung der Anforderungen messen, können Sie vorhersagen, welcher Code abstrahiert werden muss.

Wenn Sie ein Softwareentwickler in einem Team sind, planen Sie Ihr Design und zeigen Sie es Ihren Kollegen, um auch ihre Meinung einzuholen.

Seien Sie schließlich vorsichtig mit Code-Gerüchen .

Aus der allgemeinen Sicht sind sowohl zu große als auch zu kleine Klassen zu schlecht und werden als so genannte Code Smells bezeichnet. Die beiden, auf die ich mich beziehe, sind die Große Klasse (aka God Object ) und Lazy Class (aka Freeloader ) .

Hier sind die Definitionen aus der Wikipedia und der Coding Horror :

  

Große Klasse: Eine Klasse, die zu groß geworden ist.

     

Große Klassen, wie lange Methoden, sind schwer zu lesen, zu verstehen und zu beheben. Enthält die Klasse zu viele Verantwortlichkeiten? Kann die große Klasse restrukturiert oder in kleinere Klassen aufgeteilt werden?

und

  

Faule Klasse: Eine Klasse, die zu wenig tut.

     

Klassen sollten ihr Gewicht ziehen. Jede weitere Klasse erhöht die Komplexität eines Projekts. Wenn Sie eine Klasse haben, die nicht genug tut, um sich selbst zu bezahlen, kann sie dann kollabiert oder zu einer anderen Klasse kombiniert werden?

Andererseits gibt es ein Prinzip für das objektorientierte Design, das Interface Separation Principle , das besagt, dass "Clients nicht gezwungen sein sollten, sich auf Methoden zu verlassen, die sie nicht verwenden". In Ihrem Fall entsprechen die Schnittstellen mit weniger Methoden tatsächlich diesem Prinzip.

Um das oben Gesagte zusammenzufassen, ist Ihr Design ziemlich korrekt. Schnittstellen mit weniger Methoden sind gut, so dass die Klassen, die diese Schnittstellen implementieren, nicht alle Methoden zusammen mit den Methoden implementieren müssen, die sie nicht verwenden. Was die Klassen betrifft, glaube ich, dass sie irgendwann größer werden. Denken Sie daran, dass das Implementieren einer Schnittstelle nicht bedeutet, dass Sie nicht mehr Methoden haben können, als in der implementierten Schnittstelle definiert sind. Das heißt, versuchen Sie, mehr Logik dort zu setzen.

Mehr zu den SOLID , den Prinzipien des objektorientierten Designs, finden Sie auf der Wikipedia .

PS. Die Code Smells sind die Symptome von schlechtem Design und der SOLID ist die Behandlung.

Ich denke, die Frage, die Sie sich stellen sollten, ist. Ist diese Klasse verantwortlich für das, was sie tut? Die Fähigkeit, Verantwortlichkeiten zu identifizieren und zu trennen, ist ein Eckpfeiler der OOP. Sie könnten eine Security -Klasse mit nur einer Methode haben, die zum Beispiel ein zufälliges Passwort erzeugt.

Ich denke (und das ist meiner Meinung nach), dass das Zufallspasswort nur im Register verwendet wird, anstatt eine private Methode dieser Klasse zu erstellen, würde ich diese Methode in eine neue Klasse, Security , trennen, weil ich glaube nicht, dass das eine Verantwortlichkeit der Klasse Register ist.

Da es sich bei Ihrer Anwendung um eine kleine Anwendung handelt, kann es durchaus normal sein, wenige Methoden pro Klasse zu verwenden.

Wenn nicht, sollten Sie über MVC-Muster nachlesen Möglicherweise haben Sie keine Ansichten in Ihrer Anwendung, aber das Trennen von Controllern von Modellen ist eine gute Vorgehensweise.

Ihr DogFeedController scheint ein Controller und GeneralFeedStrategy das Modell zu sein. Ich möchte den Namen meiner Klassen mit dem beenden, was sie sind. Zum Beispiel UserController , UserView und UserModel . Ich denke, das macht die Sache klar, aber das ist wieder meine Meinung.

Ich sehe nicht den Punkt iDogFeedStrategy zu haben, aber ich sehe nicht das ganze Bild. Die grundlegende Verwendung einer Schnittstelle besteht darin, sicherzustellen, dass eine Gruppe von Klassen, egal wie unterschiedlich sie sind, dieselbe API besitzt und die Details jeder Klasse kapselt, die die Schnittstelle implementiert.

Bevorzugen Sie viele kleine Objekte mit komplexen Beziehungen über wenige große Objekte mit einfachen Beziehungen, da dies die Wartbarkeit begünstigt und für zukünftige Änderungen besser vorbereitet ist.

Ihr Design sieht sehr gut aus, vor allem wenn man bedenkt, dass Sie jetzt mit dem Programmieren beginnen und Anfänger immer umgekehrt arbeiten.