Aufteilung Header und Source
-
Ist eine Aufteilung von Klassen/Funktionen in Header und Source heute noch immer sinnvoll? Ich programmieren meist nicht mehr wie 20-50 Klassen. Macht es da wirklich Sinn, sich die Arbeit mit der Aufteilung in Header und Source zu machen? Welche Vorteile hätte für mich diese Aufteilung noch, außer dass es um eine Sekunde schneller kompiliert?
-
Probier es doch einfach aus.
-
HandS schrieb:
Ist eine Aufteilung von Klassen/Funktionen in Header und Source heute noch immer sinnvoll? Ich programmieren meist nicht mehr wie 20-50 Klassen. Macht es da wirklich Sinn, sich die Arbeit mit der Aufteilung in Header und Source zu machen? Welche Vorteile hätte für mich diese Aufteilung noch, außer dass es um eine Sekunde schneller kompiliert?
Selten mal: Source um static members zu definieren.
Ansonsten kannste alles in Headers lassen.
50 Klassen sind bei Dir so schnell? Gratulation zu aufgeräumtem Code.Ich lagere immer so ganz langsam die größeren Methoden um, deren Schnittstelle schon lange feststeht und gar nicht wackelt. Eher in geologischer Eile. Gerade ausreichend, daß auch nichts abschneckt, wenns auf 200 Klassen oder darüberhinaus anwächst.
Im Team immer auslagern, weils viel zu viele Leute gibt, die alles benutzen und inkludieren müssen. Und natürlich, damit man Sources im Versionskontrollsystem locken kann, ohne alle anderen Hacker zu locken.
-
Du meinst, du trennst den Code erst dann wenn die Klasse endgültig fertig ist? Das wäre auch eine Lösung. Es nervt mich nämlich tierisch, neben dem ewigen geswitche zwischen den Klassen, auch noch zwischen Header und Source wechseln zu müssen.
-
HandS schrieb:
Du meinst, du trennst den Code erst dann wenn die Klasse endgültig fertig ist?
Jup.
Frische Klassen entstehen sogar oft ohne eigene Header-Datei über der main() und wandern erst in ihren eigenen Header, wenn ich die nächste Klasse anfange.
-
Grundsätzlich finde ich das sehr sinnvoll. Ansonsten muss man sich auf Hilfsmittel wie IDE verlassen, um eine Übersicht zu bekommen, und das find ich nicht gut.
Wir haben 14 000 Klassen in unserer Software, sind einige Monster mit hunderten Methoden und zig tausend Zeilen dabei. Meist interessiert die Implementierung nicht, sondern die Schnittstelle. Wenn ich eine Klasse von einem anderen benutzen will (und das will ich natürlich ständig), schau ich schnell in den Header und seh die Schnittstelle. Der ganze Code ist an der Stelle fast immer uninteressant. Außer, die Schnittstelle ist nicht aussagekräftig genug, kommt natürlich auch ständig vor, dann schau ich mal kurz in den Code.
-
volkard schrieb:
HandS schrieb:
Du meinst, du trennst den Code erst dann wenn die Klasse endgültig fertig ist?
Jup.
Frische Klassen entstehen sogar oft ohne eigene Header-Datei über der main() und wandern erst in ihren eigenen Header, wenn ich die nächste Klasse anfange.
Mach ich auch so ähnlich.
Also erstmal drauflos coden. Typischerweise in dem File wo ich die Klassen dann auch einsetze. Einfach drüber.
Wenn das ganze zu gross wird werden Header Files gemacht.
Und wenn mir die Sache im Header File zu unübersichtlich wird, dann mach ich ein Source File. Also nicht unbedingt erst wenn die Klasse komplett fertig ist.
Und bevor ich den Teil abschliesse wird natürlich aufgeräumt.
Also spätestens dann wandert der Code aus den Header Files in die Source Files.
Mit Ausnahme von diversen Mini-Klassen, die lasse ich auch oft direkt im Header implementiert.
-
volkard schrieb:
Im Team immer auslagern, weils viel zu viele Leute gibt, die alles benutzen und inkludieren müssen. Und natürlich, damit man Sources im Versionskontrollsystem locken kann, ohne alle anderen Hacker zu locken.
locken
