Mal generell gesehen: Wie viele Klassen pro Projekt?
-
Ich möchte hier fragen, wie ein genereller Programmierstil aussieht: Sollte man in einem Projekt nun so wenige Klassen wie möglich haben (da würde z.B. eine GUI-Klasse extrem lang und unübersichtlich werden) oder sollte ich jede Klasse so kurz wie möglich halten und damit mehr Klassen erstellen? Denn ich schreibe gerade an meiner GUI Klasse und überlege, ob ich sie teilen soll in gui_main und gui_resize (Funktionen zum Resizen der GUI). Was meint Ihr?
-
Hallo,
GUIs (wie z.B. das Hauptfenster deiner Anwendung) liegen irgendwie außerhalb der üblichen Datenabstraktion. Alles was ne Menüleiste, ne Statusleiste/Toolbar und n paar Widgets hat, wird so gut wie immer kreuzhässlicher Code. Also mach dir nichts draus
Hier greifen die üblichen Regeln nicht sehr gut. Ich persönlich packe die Methoden immer in die Klasse "Mainframe", also in mein Hauptfenster rein, das wacht dann über die Dialoge usw. , damit kann man ganz gut leben.
EDIT:
Der Betreff ist irgendwie mies
MfG
GPC
-
Sollte man in einem Projekt nun so wenige Klassen wie möglich haben
Hab mal gelesen, das idealer weisse ein klasse genau eine Aufgabe erfuellen sollte. Sobald eine Klasse fuer mehr als eine von eineander logisch trennbare dinge zustaendig ist -> zu komplex.
In der Praxis sicher uebertrieben. Ausserdem laesst sich ueber den Umfang und der Teilbarkeit der "Aufgabe" immer streiten ^^
Also wenn du die Aufgaben sauber trennen kannst, es schafst die Abhaengigkeiten sehr gering zu halten, und kein wust von Parametern bei diversen Construktoren / methoden entsteht, warum nicht ? Im gegenteil, spaeter bei der Optimierung wirst dich meist leichter tun ....
Irgendwo standen mal so Richtwerte ...
ne klasse sollte nicht mehr wie 10 methoden haben ...
und ne methode nicht mehr wie 20 zeilen code ....
Kann man sich nich immer drann halten, aber klassen die das haben sind meist sehr gut wartbar ...Ciao ...
-
GPC schrieb:
GUIs (wie z.B. das Hauptfenster deiner Anwendung) liegen irgendwie außerhalb der üblichen Datenabstraktion. Alles was ne Menüleiste, ne Statusleiste/Toolbar und n paar Widgets hat, wird so gut wie immer kreuzhässlicher Code.
endlich mal jemand, der's sagt. normalerweise kriegt man bei sowas eher antworten wie "dein design ist scheisse" oder "ist zeit für ein refactoring", ohne wirklich konkrete tipps zu geben.
-
also ich mach immer eine Klasse für logisch zusammengehörende Sachen,
für jede Funktion eine Klasse halt ich für übertriebenIn deinem Fall würde ich aufjedenfall gui_main und gui_resize in eine Klasse packen
-
Ein typisches Projekt hat n Klassen...
So ne Regel gibts da nicht, kommt auch drauf an, ob man die Zeit hat,
das alles so zu planen. Aber ich versuch i.d.R. schon es übersichtlich
zu halten, und verwende viel Templates wo es sinn macht.
Die sind auch für GUI-Sachen prima, da kann man dann z.b. Widgets an
seine Datenklassen mit anschliessen, brauchts aber nur einmal coden
Aufpassen sollte man nur, das man sich keine Monsterklassen schafft,
weil das ist einfach nur unleserlich und man verstehts selbst irgendwann
nicht mehr...phlox
-
Eine Klasse pro Aufgabe ist schon richtig. Kleine Aufgaben werden dann zu grösseren Aufgaben zusammengefasst. Damit bleibt die Regel erhalten. Irgendwo gibt es in der Regel eine Applikationsklasse, die alle Aufgaben zusammenfasst. Das ist aber letzten Endes auch nur eine Aufgabe. Wie viele Klassen das dann werden, hängt ausschließlich von der Applikation ab. Da gibt es keine Regel.
-
@JPSelter
Eine Klasse ist nicht Menge von C-Funktionen plus ein paar Variablen. Den Vorschlag deine Klassen gui_main und gui_resize zeigt, dass du noch sehr funktional denkst.
Bevor du weiter machst lies dir erst einmal in einem Buch was überhaupt mit Klassen/Objekte ausgedrückt werden soll.