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

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.

tag

TUtilities hört sich für mich nicht nach einer Klasse an. Falls es nur Hilfsfunktionen ohne Membervariablen sind, würde ich daraus einen namespace machen.