Klassendesign nach Funktion oder Thema



  • Eine Frage zum Klassendesign:

    Es ist ja eine Regel, die Klassen möglichst schlank zu halten. Auf der anderen Seite ist es auch praktisch, bestimmte Themen bestimmten Klassen zuzuorden.

    Beispiel sei eine große Applikation, die einen Taschenrechner zugehörig hat.
    Man könnte eine Klasse Class calculator in calculator.cpp erstellen, und darin sämtliche Methoden des Taschenrechners abhandeln. Der Leser könnte jetzt die Klasse leicht finden, allerdings dürfte Sie auch recht groß werden. (Klassen nach Thema)

    Man könnte auch Unterklassen mit ähnlicher Namensbezeichung wählen, z.B. calc_division.cpp und calc_addition.cpp oder abgeleitete Klassen erstellen. (Klassen nach Funktion)

    Wie handhabt Ihr das Design von Klassen in größeren Applikationen? Benutzt
    Ihr eher größere Klassen nach Themen geordnet oder spaltet Ihr die Klasse noch mal auf nach Funktionen (oder ganz anders). Wie handhabt Ihr in diesem Fall die Namensgebung?

    Danke für die Hilfe.


  • Mod

    Der Taschenrechner ist der Taschenrechner. Was macht den denn deiner Meinung nach so groß? Da geht eine Eingabe rein und kommt eine Ausgabe raus, vielleicht kann er sich noch ein bisschen was merken. Das war es doch schon. Das sind nach außen zwei bis drei Schnittstellen, also eher ziemlich wenig.

    Dass eine dieser Schnittstellen ungeheuer mächtig ist, weil sie intern jede Menge verschiedene mathematische Ausdrücke verarbeiten kann, ist bei dieser Art Überlegungen egal.



  • Man muss Klassen nicht zwangsweise aufdröseln, bis auf das kleinste Element.
    Diese Regel bedeutet im Prinzip, dass man keine nicht alles in eine Klasse stopfen soll. Zum Beispiel braucht eine Klasse für Mathematik Funktionen nicht wissen, wie die Ein- und Ausgabe gehandhabt wird, mal als blödes Beispiel.

    Aber manchmal werden Klassen einfach sehr umfangreich und es gibt wenig, das man dagegen tun kann. In der Spieleprogrammierung als Beispiel. Dort willst du deine allgemeine Hierarchie so flach wie möglich halten und für einzelne Klassen werden etliche Elemente benötigt, weil diese Daten einfach nötig sind. OpenGL Identifier, Matrizen, Vektoren, Positionsdaten, vorberechnete Collision Shapes, Farbdaten etc. All das summiert sich und eine Sprite Klasse wächst so schnell mal eben auf 10-20 Membervariablen an.

    Man muss hier IMHO selbst für jedes Programm das man schreibt die Balance finden und es gibt einfach keine universelle Antwort dafür.



  • SeppJ schrieb:

    Der Taschenrechner ist der Taschenrechner. Was macht den denn deiner Meinung nach so groß?

    Das war nur ein Beispiel, es könnte auch eine größere Klasse sein. Hintergrund war das Single Responsibility Principle für Klassen.


  • Mod

    TauCeti schrieb:

    SeppJ schrieb:

    Der Taschenrechner ist der Taschenrechner. Was macht den denn deiner Meinung nach so groß?

    Das war nur ein Beispiel, es könnte auch eine größere Klasse sein. Hintergrund war das Single Responsibility Principle für Klassen.

    Allgemein ist die Antwort: Nach Funktion. Das ist schließlich das, was ein Klassenobjekt macht: Es tut etwas. Thematische Aufteilung wäre eher ein Fall für Namespaces.



  • Nicht Themen Klassen zuordnen. Und auch nicht nach Funktionen.

    Klassen sind Entitäten, die Objekte der Applikation repräsentieren.

    Wenn Du eine Applikation designst, solltest Du Dir überlegen, aus welchen Objekte sie besteht. Man könnte auch sagen, aus welchen Gegenständen. Objekte haben Zustände, also Eigenschaften und Methoden, die auf diesen Eigenschaften arbeiten.

    Ein Taschenrechner hat möglicherweise Tasten, bzw. Buttons, die als Eigenschaft z. B. einen Zahlenwert haben und die man drücken kann. Ein Taschenrechner hat auch eventuell einen Rechenstack, auf dem man Zwischenergebnisse speichern und wieder zurück holen kann.

    Klassen sind nicht dazu da, irgendwelchen logischen Funktionen zusammenzufassen. Wie bereits gesagt wurd, kann man Namespaces dazu verwenden oder einfach Dateien.



  • Du könntest auch eine public Klasse Calculator mit paar wenigen Funktionen anbieten. Und dann machst du dir ein Verzeichnis impl oder internal oder wie auch immer und machst da zig Klassen/Dateien rein, die nur für die Implementierung benötigt werden.



  • Eine Klasse -> Eine Aufgabe.

    Das SOLID-Prinzip sagt, das man nur einen Grund haben darf, um eine Klasse zu ändern.

    Natürlich ist das alles die Extrem-Variante. Aber da die Praxis zeigt, das man sehr leicht und schnell unfreiwillig davon abweichen wird, sollte man immer an die Extrem-Variante denken damit es nicht noch schlimmer wird.

    Ich fahre immer am Besten, wenn ich mich an diese Regel halte. Das tolle ist, das ich dann meistens die vielen kleinen Klassen beliebig kombinieren kann um am Ende eine Steuerklasse zu bauen, die aber auch nur klein ausfällt, weil sie Members nur kombinieren muss.



  • k.T.


Log in to reply