CPP-Dateien werden zu groß und unübersichtlich

Wie kann ich das umgehen? In den Headern liegt die Klassendeklaration und die Funktionen in den zugehörigen cpps.

Nur irgendwie ist das doch total unübersichtlich wenn ich eine klasse

class bla
{
150 Millionen Funktionen
};

habe, dann ist das zugehörige cpp file doch nicht mehr durchschaubar? Schon gar nicht für außenstehende.

prolog

Hallo,

Wenn deine Klasse "150 Millionen Methoden hat" solltest du dein Design überdenken.

War es echt nicht ersichtlich das das ein Beispiel war.......

Schau dir mal den JA2 Source an, dann weißt du worauf ich hinaus will, imho sind die c-dateien viel zu überladen.

Geht das echt nicht anders? Bzw. wird das echt nicht anders gemacht?

RHBaum

Headern liegt die Klassendeklaration und die Funktionen

funktionen in klassen = Methoden !!!

class bla
{
150 Millionen Funktionen
};

Das ist ne prinzipielle Designfrage.

150 Millionen sind etwas viel.
Man sollte eine Klasse so definieren, das sie nur eine bestimmte funktionalitaet implementiert.
Das heisst meist, das sie nur paar wenige (10 vielleicht ??? ) benutzerdefinierte funktionen hat, + konstruktoren + destruktor + Ops die man braucht .... dann bleibt die sache ubersichtilich.
Die klasse die mehr funktionalitaet beinhaltet sollte dann aus mehreren Klassen (Aggregation) bestehen, die jede einen teil der gesamtfunktionalitaet beinhaltet.

Zu deutsch, ne schnittstelle mit 100+ methoden ist schlechtes logisches design. -> Aufspalten in teilfunktionalitaeten und mehrere klassen ....

Ciao ...

prolog

Printkey schrieb:

War es echt nicht ersichtlich das das ein Beispiel war.......

Schau dir mal den JA2 Source an, dann weißt du worauf ich hinaus will, imho sind die c-dateien viel zu überladen.

Geht das echt nicht anders? Bzw. wird das echt nicht anders gemacht?

Natürlich war es das. Das Prinzip ist aber das selbe, wenn du zu viele Methoden hast solltest du überlegen ob deine Klasse nicht etwas zu viel kann. Das ist dann eine Designfrage.

RHBaum

JA2 Source

JA2 = Jagged Alliance 2 oder so ???

wenn ja: spiele sind meist nie der Beweis der Existenz eines guten OOP Desing. Bei Spielen hasst ja teilweisse schon Glueck, wenn es ueberhaupt klassen gibt.

"Gute" beispiele:
Schau dir mal die sourcen von STLPort an, oder dem Xercess C++ Parser ...
boost ist bestimmt auch ned schlecht (hab ich mir ned angeschaut)

Prinzipell
Meist (es gibt immer Ausnahmen) findet man den besseren Code (in sachen OOP Design + Portabiliataet + Sicherheit) in portablen Programmen. Was fuer ein bestimmtes System geschrieben ist, benutzt auch meist unportable systemspeziefische Tricks.
Da Libraries wesentlich hoehere Anforderungen haben als fertige Programme, wird man da auch meist eher fündig.

Ciao ...

Und was ist wenn die Methoden aber so groß sind das sie das file unübersichtlich machen? Klar, in teilaufgaben aufteilen was ich gemacht habe und natürlich, sofern man es kann, so gut programmieren das man kleine methoden hat.

Mit dem "das die Klasse zuviel kann":

Ich habe eigentlich eine aufgabe und hab mir gerade 3 Klassen erstellt, eine hilft mir komfortabel mit zeiten zu hantieren, die andere gibt mir generelle infos zu best. dateien und die dritte analysiert diese dateien.

streng genommen ist das alles eine funktionalität:
untersuche datei, mach was damit.

Jetzt hab ich 3 klassen und grübel schon ob ich nicht noch eine vierte mache, für schreiben in neue dateien.

Soll ich diese 4 Klasse jetzt in einer klasse (ka, "datei" evt.) zusammenfassen?
Falls ja hat jemand ein tutorial, sowas habe ich noch nie gemacht...

RHBaum

Gibt sicher ne Menge Literatur zu (sprachunabhaengigen) OOP design. Was ich hatte, war aber meisst sehr Sch<zensiert> zu lesen. Trocken und zu abstrakt. Naja, ist auch nen abstraktes Thema.

Nen Schubs in die richtige Richtung bekommt man aber auch durch angrenzenden Themen:
Zum beispiel die ganze Policy Geschichte aus "Modern C++" lenkt die Aufmerksamkeit auch in die richtigen Pfade.
Viele C++ spezifischen Buecher beschaeftigen sich mit der Discrepanz zwischen guten OOP Design + LaufzeitOverhead und wie man den overhaed trotz guten Designs gering haelt (Templates <-> Vererbung, inline und was der compiler kann ... )
Design Pattern ist auch ne gute Hilfe in die richtige Richtung weil es Loesungen von Teilproblem behandelt, die erst mal so weit runter abstrahiert werden muessen ...

Wenn einer nen wirklich gutes Buch über OOP Design weiss ... wuerd mich auch intressieren.

Ciao ...

Shade Of Mine

Printkey schrieb:

Und was ist wenn die Methoden aber so groß sind das sie das file unübersichtlich machen?

Mehr als 10 Zeilen? dann passt was nicht.

Sieh es ein: du hast ein Designproblem.

streng genommen ist das alles eine funktionalität:
untersuche datei, mach was damit.

*lol*

Nein. Sonst hätte ja das ganze Progamm nur eine Funktionalität: löse das Problem.

Ne, du musst spezifizieren.

Soll ich diese 4 Klasse jetzt in einer klasse (ka, "datei" evt.) zusammenfassen?

Nein. Wenn sie andere Aufgaben haben dann nicht.

wenn du 500 Zeilen code pro Klasse hast, dann hast du zuviel Code und solltest dir etwas anderes überlegen

Nur 10 Zeilen wirklichen Code

Vielleicht habe ich ja auch ein Designproblem, ich weiß es nicht. Vielleicht stelle ich mich auch nur komisch an, weil mir persönlich das zu unübersichtlich ist.

Aber wie soll man z.b. diese Methode kürzen:

unsigned int Check_Tolerance_Time(ifstream &playerLogfile, ofstream &convertedLogfile, unsigned int toleranz)
{	
	CTime CTime;

	convertedLogfile<<"Zeitüberschreitungen (angegebene Toleranz: "<<toleranz<<" Sekunden):"<<endl;
	convertedLogfile<<"--------------------------------------------------------------------"<<endl<<endl;

	for(string Read; getline(playerLogfile, Read);)
	{
		// History und Bitstatus Nachrichten auslassen
		if(Read.substr(51,3) != "HST" && Read.substr(55,10) != "BIT_STATUS")
		{
			CTime.Set_Read_String(Read);

			// Keine Zeitsynchronisation gegeben?
			if(CTime.Get_Time_Difference() == -1)
			{
				convertedLogfile<<Read<<endl;
				convertedLogfile<<"Gesendet : "<<CTime.Get_Sent_String()<<endl;
				convertedLogfile<<"Empfangen: "<<CTime.Get_Received_String()<<endl;
				convertedLogfile<<"Keine Zeitsynchronisation"<<endl<<endl;
				continue;
			}

			if(CTime.Get_Time_Difference() > toleranz)
			{
				convertedLogfile<<Read<<endl;
				convertedLogfile<<"Gesendet : "<<CTime.Get_Sent_String()<<endl;
				convertedLogfile<<"Empfangen: "<<CTime.Get_Received_String()<<endl;
				convertedLogfile<<"Differenz: "<<CTime.Get_Time_Difference()<<" Sekunden"<<endl<<endl;		
			}
		}
	}

	return(1);
}

Die anderen sind meist kleiner aber niemals untern 10 zeilen hardcode....
Klar, "Billigmethoden" sind klein, aber auch keine womit man analysiert:

// Liefert die Sendezeit als String zurück
string CTime::Get_Sent_String()
{
	string sent;

	sent = m_line.substr(40,10); 

	return(sent);
}

unsigned int Check_Tolerance_Time(ifstream &playerLogfile, ofstream &convertedLogfile, unsigned int toleranz) 
{    
    CTime CTime; // UH YEAH! Na wenn das mal gut geht?

Shade Of Mine schrieb:

Printkey schrieb:

Und was ist wenn die Methoden aber so groß sind das sie das file unübersichtlich machen?

Mehr als 10 Zeilen? dann passt was nicht.

Naja also "nur" 10 Zeilen ist doch nich viel Also meine Funktion zur Erkennung der CPU und der Grafikkarte die wir in der Firma benuten ist ca. das 30 Fache von 10 Zeilen, zwar gekapselt, aber Assemblercode halt

Ich finde ein limit von 40 Zeilen gut, jedoch man sollte auch nicht zu viele Funktionen basteln, da es sonst sehr unübersichtlich wird.

Ungetestet, aber compilieren lässt es sich. Ich sage dir bescheid obs geht

Ich habe mir übrigens gerade einfach mal irgendeine jagged alliance 2 c datei angesehen,

über 4000 zeilen lang.

Wobei ich da aber auch gerade eine funktion gesehen hab die mit sicherheit 500 zeilen groß ist

Aber ok, gut ihr meint das soll so sein, dass gehört sich so das ist standard.
Wenn das so ist werfe ich jetzt meine Bedenken über Bord und mache es genau so, ok?

RHBaum

Aber ok, gut ihr meint das soll so sein, dass gehört sich so das ist standard.

Wer sagt das ? liest du auch was wir schreiben ?
50 Zeilen ist nen guter Anhaltspunkt, find ich ...

Wenn das so ist werfe ich jetzt meine Bedenken über Bord und mache es genau so, ok?

Wenn ich Dein Projektleiter waer, und du koenntest mir keine wirklich gute Begruendung nennen ... dann wuerdest du den Rest deiner Tage in der Firma SoftwareTester spielen, und Fehlerprotokolle per Hand auswerten !!!
Dein PC wurde an die Minimalanforderungen fuer den Kunden angepasst und der C++ kompiler sofort deinstalliert/ oder nicht wieder installiert !!!

Ciao ...

Diesmal stehe ich wohl auf der Leitung,

ihr schreibt ich hätte ein Designproblem und seit unterschiedlicher Meinung bei der länge der Methoden (bis 10, bis 50), seit euch aber einig das die Methoden zu einer Klasse in einer Datei landen.

Dann frag ich ob ich das jetzt richtig verstanden habe, weil ich es dann übernehme obwohl es mir persönlich nicht schmeckt :p

seid hier mit d, ich weiß

RHBaum

Sieh das mit der Zeilenzahl nicht ganz zu eng !

immer unter 10 zu bleiben, ist eh nen Problem.
100+ Zeilen sind meist zu viel.

viel ist geschmackssache.
Wichtig ist, dass du und auch andere es als uebersichtlich und verstaendlich empfinden.

Manche zaehlen Kommentarzeilen mit, manche schreiben gar keine im Funktions-Rumpf

Manche komprimieren ihren code sehr stark, manche schreiben ausfuehrlicher und hoffen auf die optimierung durch den compiler ...

pX ? px->machwas() : cerr << "Aerger ! ";

if(px)
    px->machwas();
else
    cerr << "Aerger ! ";

if(px)
    {
        px->machwas();
    }
else
    {
        cerr << "Aerger ! ";
    }

Also 50 Zeilen sind bei mir sehr relativ

Ciao ...

Ich hatte das so verstanden das er 10 Zeilen Hardcode meinte
Das ist imho zu wenig, dein Wert ist gut, bis zu 50 Hardcodezeilen sind in Ordnung

RHBaum

seit euch aber einig das die Methoden zu einer Klasse in einer Datei landen.

wie meinst du das ?

Die Methoden einer klasse sollten in einer Datei stehen ... klar.
Aber eine Datei kann mehrere Klassen beinhalten / sowohl definitionen(cpp) als auch deklarationen(h).
Mach ich zumindest auch ab und zu, wenn die Klassen synthaktisch eng zusammengehoeren ... und ned allzugross sind.

Ciao ...