Objektorientierte Programmierung

[vsilverlord]

Hallo leute,
um meine klassen erstellen und verwalten benutze ich den UMLed UML-Editor, von dem habe ich nämlich auch eine Lizens (von der Schule).
Das Problem ist, dass ich mittlerweile ziemlich viele Klassen erstellt habe, und wenn man mit dem Editor eine neue Klasse erstellt, muss man die zwangsläufig in eine neue Unit reinsetzen, und somit enstehen tausende verschiedener Units, was eigentlich total unnütz ist. Wenn ich jetzt einfach alle Klassen in eine Unit reinpacke, versteht das der Editor nicht mehr, und das ist ja eigentlich nicht Sinn der Sache, wenn ich zb. die Units verändern möchte oder anpassen will, würde ich das nämlich gerne mit dem Editor machen.
so, was nun? Kennt ihr einen besseren Editor? Der Editor versteht nämlich noch mehr Sachen nicht, beispielsweise properties kennt er nicht. Oder habt ihr eine Lösung für mein Problem?

[Phoenix]

Eine Klasse gehört in eine Datei.
Mehrere Klassen in eine Unit zu packen is unsauberer Stil und sollte wenn möglich vermieden werden.

Ansonsten halte ich persönlich nicht viel, von UML heraus klassen zu generieren.
Andersrum wird eher ein schuh draus (aus einer Klasse ein Diagramm erzeugen -> zu Dokumentationszwecken).

Der Hintergrund ist einfach: Man muss beim entwickeln sonst zu oft das Tool wechseln. Die Unit-tests designed man ja auch nicht in UML sondern schreibt den Test im Code. Dann kann man die klasse die getestet wird auch unmittelbar danach im Code schreiben. AUsserdem ist man in aller Regel an der tastatur schneller als mit der maus in einem designer.

[Luckie]

Zitat:

Zitat von Phoenix

Eine Klasse gehört in eine Datei.
Mehrere Klassen in eine Unit zu packen is unsauberer Stil und sollte wenn möglich vermieden werden.

Das würde ich nicht so pauschal sagen. Klassen die zusammengehören mache ich auch in eine Unit. Es sei denn ich habe das Gefühl, dass mir die Unit zu groß wird.

[Phoenix]

Lese mal Clean Code ;-)

[Luckie]

Habe ich. Ich glaube, ich habe das hier auch mal vorgestellt. Aber das bedeutet ja nicht, dass man davon abweichen kann, wenn man der Meinung ist, dass es anders besser ist. Ich sehe das Buch so, dass es Ratschläge und Hinweise enthält, wie man besseren Code schreiben kann. Allerdings muss man sich nicht sklavisch daran halten. Man sollte immer noch selber entscheiden, wie man etwas macht. Genauso wie der Styleguide von Borland auch nur ein Ratschlag bzw. Hinweis ist, wie man Code formatieren sollte.

[Phoenix]

Das schon, aber die Stelle ist extrem gut Begründet.
Wenn ich wissen will, was es für Änderungen an einer Klasse gegeben hat, dann gucke ich mir die History dieser Klasse (=Datei) in meiner Quellcodeverwaltung an. Sind da nun MEHR als eine Klasse drin, dann erhalte ich mit dieser History jede Menge unnütze Informationen (Änderungen an anderen Klassen, die mich nicht interessieren und nur ablenken).

Ausser natürlich, man benutzt keine Versionierung. Aber das ist ja schon eher gröbste Pflichtverletzung als Entwickler ;-)

[vsilverlord]

tut mir leid, ich versteh das nicht mit dem 'eine Datei daraus machen'. Wie funktioniert das? Das mit der Versionierun hört sich gut an. Aber ohne den UML-Editor zu arbeiten, halte ich eigentlich bei dem jetzigen Zweck für nicht für so sinnvoll, da ich total viele verschiedene Objektklassen habe, und die sind alle von einem 'Oberobjekt' vererbt. Wäre es nicht praktisch, die alle in eine Unit reinzupacken? Gibt es noch elegantere Lösungen? Ich bin für alles offen, auch etwas neues auszuprobiern.
Gruß

[Phoenix]

Zitat:

Zitat von vsilverlord

Wäre es nicht praktisch, die alle in eine Unit reinzupacken?

Aus oben genannten Gründen eher nein. Eine Klasse sollte in einer Unit stehen. Um das sauber zu haben steht bei mir sogar jede Enum und jeder Record in einer eigenen Unit.

[LDericher]

Zitat:

Zitat von Phoenix

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

Das grenzt ja schon an Psychosen :D
Und... Versionierung... von Hand oder gibts dafür auch ne IDE-automatisierte Möglichkeit? :gruebel:

Gruß LDer

[divBy0]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von vsilverlord

Wäre es nicht praktisch, die alle in eine Unit reinzupacken?

Aus oben genannten Gründen eher nein. Eine Klasse sollte in einer Unit stehen. Um das sauber zu haben steht bei mir sogar jede Enum und jeder Record in einer eigenen Unit.

Ich hab' auch ganz gern Records in einer eigenen Unit. Mehrere Klassen packe ich z.B. nur in eine Unit, wenn die Klassen relativ klein sind und das ganze nicht unübersichtlich wird.

[Phoenix]

Zitat:

Zitat von LDericher

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

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 :shock:.
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:

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:

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:

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.