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

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.

Unix-Tom

Ich gluabe ihr sprecht hier über etwas was 'Gen.d.Pz.Tr.Seb' garnicht hat.

@Gen.d.Pz.Tr.Seb:
Du hast einen großen Fehler gemacht. Du hast UI nicht von Funktion getrennt.
Hier kommt es jetzt darauf an was dein Programm machen soll. z.B. gehört eine Datenbankabfrage nicht in die UI-Klasse. Berechnungen gehören da nicht rein, etc.

@Unix-Tom.

Ich habe eben leider alles in einer monster Klasse gehabt. Jetzt hab ihc eh die Arbeit und zersplitte diese so wie du es meinst bzw. wie es wohl alle andren vor dir auch gemeint haben.

Mal eine allgemeine Frage (will jetzt aber nicht ind c++ forum gehen, und suchen geht nicht mehr (so weit ich weis));

Ich habe jetzt 4 Klassen; TRichEditUtilities, TEingabefeldUtilities, TListViewUtilities und TUtilities. Wie kann jetzt Utilities alles erben von den andren drei Klassen??
Geht das irgendwie auf einmal?
Oder muss zuerst TEingabefeldUtilities von TRichEditUtilities erben, dann ListViewUtilities, TEingabefeldUtilities erben und zuletzt TUtilities TListViewUtilities erben?? (Und jede Klasse fügt dann eben 'ihren code' dazu)

Gregor

Gen.d.Pz.Tr.Seb schrieb:

Ich habe jetzt 4 Klassen; TRichEditUtilities, TEingabefeldUtilities, TListViewUtilities und TUtilities. Wie kann jetzt Utilities alles erben von den andren drei Klassen??
Geht das irgendwie auf einmal?
Oder muss zuerst TEingabefeldUtilities von TRichEditUtilities erben, dann ListViewUtilities, TEingabefeldUtilities erben und zuletzt TUtilities TListViewUtilities erben?? (Und jede Klasse fügt dann eben 'ihren code' dazu)

Vererbung macht man da, wo eine "ist ein"-Beziehung vorliegt, also da, wo eine Klasse eine Spezialisierung einer anderen Klasse ist. Das läßt sich hier schonmal überhaupt nicht mit deiner Namensgebung vereinen. "TUtilities" ist ein "allgemeinerer" Name als die anderen 3. Insofern ist entweder die Namensgebung falsch oder es ist keine Vererbung angebracht.

Mehrfachvererbung, wie du sie da gerne hättest, ist mit C++ möglich. Allerdings kommt es mir so vor, als ob du dir bei dieser "Vererbungsfrage" die Frage stellst, was du gerne in einer bestimmten Klasse hättest. Du solltest dich aber eher fragen, was eine bestimmte Klasse ist. Wenn du Vererbung falsch anwendest, dann wird es schwer, die Struktur deines Programms zu verstehen. Wenn es also nur darum geht, bestimmte Funktionalitäten in eine Klasse zu bringen, dann ist vielleicht ein anderes Design angebracht. Es gibt da genug Möglichkeiten.

Wenn hier TUtilities eine Spezialisierung der anderen Klassen sind, solltest du dir überlegen, ob die anderen Klassen untereinander vielleicht auch Spezialisierung von einander sind. In diesem Fall ist keine Mehrfachvererbung angebracht, sondern die zweite Variante, die du oben schon ansprichst.

Vielleicht haben deine Klassen ja auch nur eine Gemeinsamkeit, die in einer abstrakten Superklasse zu finden ist, die du noch garnicht geschrieben hast. In diesen Fall sind parallele Vererbungslinien angebracht.