Objektorientierte Programmierung

[Phoenix]

Zitat von LDericher:

Und... Versionierung... von Hand oder gibts dafür auch ne IDE-automatisierte Möglichkeit?

Versionierung mache ich mittels Subversion. Es gibt dafür IDE Plugins für Delphi, aber das meiste mache ich tatsächlich mit TortoiseSVN im Windows Explorer - bzw. weil ich ja im Moment mehr Delphi Prism mache mit AnkhSVN im Visual Studio. Mit dem VisualSVN Server ist der Subversion-Server übrigens in 3 Minuten komplett aufgesetzt. Oder man macht ein Lokales Repository, da braucht man dann nur Tortoise für.

Und das hat nichts mit Psychosen zu tun, du solltest mal sehen wie unordentlich meine Wohnung ist .
Aber mein Quellcode ist mein Kapital, und das muss ich pflegen. Und dazu gehört eine bestimmte Ordnung. Ausserdem kann ich dann anhand meiner Tests leichter herausfinden, was getestet ist was nicht. Wenn ich mehrere Klassen in einer Unit habe, dann habe ich ja mehr als nur die Tests die für eine Klasse die auf diese Unit verweisen. Wenn dann mal was fehlschlägt, dann weiss man nicht sofort, was jetzt auf einmal kaputt ist.

[vsilverlord]

ich hab ja delphi 2009. Und neuerdings, also im Unterschied zu Delphi 7 gibt es da jetzt so ein button 'history' neben 'code'. Da sind die ganzen verschiedenen Versionen mit Datum und Speicherungsdatum aufgelistet. Heißt das, dass ich das, was Phönix erwähnt hat, nun nicht mehr machen muss, weil das mein Delphi übernimmt, oder ist das eher unsicher?
Eine weitere Frage: Wenn ihr etwas vererbt, und mehrere kinder einer instanz habt, und nun braucht ihr in der verwaltungsunit oder was auch immer alle kinder samt den eltern, bindet ihr dann alle units nochmal extra ein? oder wie kann man das machen?
gruß

[Phoenix]

Also das 'History' tab ist einfach ein Backup der Datei. Bei jedem SPeichern wird eine neue History-Datei angelegt. Eine echte Versionierung ist das aber nicht - und diese Historie ist auch nur lokal vorhanden.
Ich verwende die Historie nur, um mir die Zwischenstände zischen dem letzten Checkin und jetzt aufzubewahren.

[alzaimar]

Zitat von Phoenix:

Um das sauber zu haben steht bei mir sogar jede Enum und jeder Record in einer eigenen Unit.

Solchen Code musste ich mal übernehmen. Der Programmierer hatte sich aus dem Staub gemacht. Das ist in meinen Augen Blödsinn gewesen. Wenn Du damit klar kommst, kein Problem. Aber jede kleine Pupsdeklaration in eine eigene Datei zu schreiben war und ist für mich sehr umständlich zu warten und zu lesen.

Zitat von Phoenix:

Lese mal Clean Code

Ich schmeiss auch nicht jede Klasse in eine eigene Datei (Aber fast jede). "Clean Code" hin oder her. Schließlich ist das kein Gesetz und man argumentierte ewige Zeiten auch mit der 'Wahrheit', das die Welt eine Scheibe sei. Ich kann von mir behaupten, das ich mindestens so lange Programme schreibe, wie der Autor und wieso soll der so viel mehr Weisheit besitzen als ich? Also, immer Butter bei die Fische, oder wie das heißt.

Der Ansatz des Threaderstellers allerdings ist naiv. Wenn ich die Wahl zwischen "Entweder pro Klasse eine Datei oder alle Klassen in eine einzige Datei" würde ich die erste Wahl eindeutig bevorzugen. Tendentiell ist es übersichtlicher, jede Klasse in eine eigene Datei zu packen.

[sx2008]

Zitat von alzaimar:

Wenn ich die Wahl zwischen "Entweder pro Klasse eine Datei oder alle Klassen in eine einzige Datei" ...

Das Optimum liegt irgendwo dazwischen. Borland hat das mit seiner VCL ganz gut hingekriegt.
Klassen, die engen Zusammenhang haben (z.B. durch Vererbung oder Ableitungen von TCollection & TCollectionItem)
sollten in einer Unit beieinander gehalten werden.
Es kommt einfach darauf an, ob die Klassen, Deklarationen, Records,... eine hohe oder niedrige Kohäsion haben.