1 große Klasse. Oder doch viele kleinere??

Ich habe jetzt in einer Klasse 4000 Zeilen .cpp und nochmal 2000 Zeilen .h.
Von dieser Klasse wird eigentlich immer nur eine einzige Instanz ausgeführt. (Weils das Hauptprogramm ist)

Irgendwie etwas unübersichtlich.

Es wäre mir möglich die Klasse in mehrere kleinere, aber übersichtlichere Klassen aufzuteilen.

Es könnte dadurch vielleicht etwas übersichtlicher werden, aber ich weis nicht ob es einen Sinn hat da die jeweiligen Klassen wiederum nur einmal aufgerufen werden.

Würd gern mal eure Meinung (und Erfahrungen) hören.

Erzähl uns doch am besten mehr über die Klasse.

Gregor

Auf 4000 Zeilen Programmcode kommen bei mir etwa 60-80 Klassen. Eine große Klasse hat bei mir eigentlich immer noch weniger als 300 Zeilen Code. Mit diesen Größen habe ich eigentlich keinerlei Probleme bezüglich der Übersicht.

4000 Zeilen für eine Klasse sind aus meiner Sicht somit absolut abnormal und ich wette, dass diese Klasse nicht mit den üblichen Entwurfsmustern vereinbar ist. Achtest du z.B. auf eine Trennung von M,V,C?

Gregor schrieb:

4000 Zeilen für eine Klasse sind aus meiner Sicht somit absolut abnormal und ich wette, dass diese Klasse nicht mit den üblichen Entwurfsmustern vereinbar ist.

Vielleicht kennst du den Borland Builder? Auf einen Button klicken und schon ist eine neue Funktion da. Da kommt mit der Zeit gewaltig was zusammen.

Aber aus der Zeit bin ich heraus. Jetzt möcht ich selber meine Klassen machen.

Habe auch schon Teile 'ausgegliedert'. Aber diese 'neue' Klasse hat immer noch 600 Zeilen!

Gregor schrieb:

Achtest du z.B. auf eine Trennung von M,V,C?

Ich weis ehrlich gesagt nicht was du meinst

Das MVC Design Pattern ist keine Pflicht und ehrlich gesagt, überzeugt es mich nicht. Das muss aber nichts heißen, weil der Prof es halt einfach nicht rübergebracht hat und ich noch nicht selber recherchiert habe.
Auf jeden Fall sind IMHO so abnormal große Klassen ein Hinweis auf schlechtes Design.

Optimizer schrieb:

Auf jeden Fall sind IMHO so abnormal große Klassen ein Hinweis auf schlechtes Design.

Jup, glaub ich auch. Das war halt mit dem Builder so einfach. Jetzt versuche ich eh umzudenken bzw. umzuschreiben.

Aber soviele Klassen von denen es dann vielleicht eine Instanz gibt?

Gelernt habe ich dass nie wie groß Klassen sei sollen. Deshlab frage ich ja auch. Und vor allem ob sich das lohnt wenn es nur eine Instanz gibt. In der tollen ( ) Schule habe wird gerade mal ein bisserl C gelernt. Den Rest habe ich halt so 'zusammengekratzt'.

Gregor

Gen.d.Pz.Tr.Seb schrieb:

Gelernt habe ich dass nie wie groß Klassen sei sollen. Deshlab frage ich ja auch. Und vor allem ob sich das lohnt wenn es nur eine Instanz gibt.

1. Es gibt keine Faustregel bezüglich Klassengrößen. Ich kann mir durchaus vorstellen, dass in bestimmten Fällen auch extrem große Klassen angebracht sind. Um das bei deinem Fall sagen zu können, müßte man die Klasse sehen.

2. Es ist durchaus üblich, Klassen zu haben, von denen es nur eine Instanz im laufenden Programm gibt. -> Stichwort: "Singleton".

Gregor

Optimizer schrieb:

Das MVC Design Pattern ist keine Pflicht und ehrlich gesagt, überzeugt es mich nicht.

Ok, ehrlich gesagt bin ich auch gerade dabei, etwas davon wegzukommen. Ich schwenke momentan zu einem etwas deklarativeren Programmierstil um, bei dem ich nur "M" schreibe und den Rest zur Laufzeit mit Hilfe eines kleinen Frameworks aus dem verfügbaren "M" generiere. (wobei ich glaube, dass sich dieser "Stil" in C++ noch schwieriger umsetzen läßt als in Java, womit ich ja größtenteils programmiere)

Ich kann meine Monster Klasse aufsplitten. Das werd ich jetzt auch tun.

Aber vermutlich (weis noch nicht inwieweit ich das Programm weiter entwickle) wird es von ziemlich vielen Klassen dann nur eine Instanz geben. Ist dass dann auch noch 'gut' selbst wenn 60% der Klassen eine einzige Instanz haben??

G4M3M4St3R

Hallo Gregor,

Gregor schrieb:

Ich kann mir durchaus vorstellen, dass in bestimmten Fällen auch extrem große Klassen angebracht sind.

ich kann mir nicht vorstellen das große Klasse sinnvoll sind da diese, im gegensatz zu kleinen Klassen, viel schwerer zu warten sind. Außerdem sehe ich den Sinn der objektorientierten Programmierung darin, möglichst viele wiederverwendbare "Bausteine" zu schreiben - ob dies mit so einer Klasse noch möglich ist, wage ich zu bezweifeln. Es gibt zwar bestimmt Klassen die nicht mehr aufgespalten werden können, solchen bin ich aber bis jetzt noch nicht begegnet.

Grüße

will auch mal was zum thema sagen, das kommt doch an welches probelm man modeliert.
wie heisst die klasse den? normalerweise ist eine klasse ein speichercontainer mit den dazugehörigen methoden um die atributte zu manipulieren. klassenname wie grafikzeichen sind sogesehen keine klassen sondern funktionen. viele trennen aber nicht klassen mit funktionen. klassen sind imho Objekte die etwas darstellen. nehmen wir mal ibm's middleware als bsp. Kennt ihr doch wo der typ auf der strasse die info bekommt, der aktienkurs ist gesungen, die in der zentrale machen was die anderen machen was und der typ verkauft dann. oder so middleware ( auto zu reparieren, ware wird autom bestellt, dingsbums wird gemacht, kunde kann auto zum termin fristgerecht abholen )

so ein modell zu programmieren braucht man viele klassen, welche miteinander kommunizieren. das in einer klasse zu machen ist dxxxx. Also mich würd interessieren wie deine klasse heisst.

operator void

"One class, one responsibility" ist eine gute Faustregel. Damit ergibt sich meistens von ganz allein eine Trennung in angenehm kleine Klassen. Wenn's nur eine Instanz gibt - wurscht. Die Elemente dieser einen Instanz sind trotzdem sicher durch ihr Interface geschützt.

...aber na ja, dass die UI da meistens nicht ganz mitspielt, habe ich auch gemerkt. Dann sollte die UI immerhin so einfach wie möglich sein und die ganze Arbeit abdelegieren. Die eigentliche Programmlogik aufzuteilen sollte aber recht einfach gehen.

operator void schrieb:

"One class, one responsibility" ist eine gute Faustregel.

Gut. Das kann und werd ich mir merken. Aber es jetzt anzuwenden wird nicht einfach bei dem code - Haufen.

operator void schrieb:

Wenn's nur eine Instanz gibt - wurscht.

Da kann ich mich auch dran halten. Und vielleicht gibt mir dieser Aus- bzw. Umbau meines codes die einfacheren Mittel mein Programm einmal weiter zu entwickeln. :p

Ich habe das Gefühl ich werd diese Ferien länger vorm NB sitzen...

Sag doch mal bitte wie deine Klasse im moment heißt.

Genau wie mein Programm. Ah nein nicht ganz. Ein 'T' ist auch noch davor.

Jetzt nicht kritisieren! Ich weis dass ich keinen (und zwar wirklich keinen) stil habe und nun alles mal besser oop machen muss!

TSTC? lol

korrekt. Mir ist nichts besseres eingefallen.

Wenn ich jetzt eine Klasse mache die z.B.: nur die Eigenschaften eines RichEdits behandelt und diese ist ca. 500 Zeilen lang. Soll ich dann immer noch schauen das ich dass weiter unterteilen kann oder kann ich dass jetzt einfac mit der Begründung 'One class, one responsibility' stehen lassen??

also ka
aber man kann immer in modulen programmieren

eines wäre z.b. für die grafische ausgabe
eines fürs netzwerk/protokolle
eines für ....

was sehr hilft ist die UML Modellierung. Von dort kann man viel lernen.

volkard

newkid schrieb:

was sehr hilft ist die UML Modellierung. Von dort kann man viel lernen.

Das glaube ich nicht, Tim.