Struktur der Klassenbibliothek

[derRaab]

Hallo Leute,

ich fange eigentlich reichlich spät an mir eine Klassenbibliothek anzulegen, aber besser spät als nie. Bis jetzt habe ich immer neue Pakete geschrieben oder per Copy und Paste einen Teil in ein neues Projekt eingefügt usw.

Da ich mich gerade mit dem Thema Design-Patterns beschäftige und das ein oder andere bereits entwickelte Klassenpaket neu erstelle, wollte ich mal nachfragen wie man die denn dann am besten strukturiert.

Ich habe jetzt einfach in Eclipse ein neues Projekt "ActionScriptLibrary" angelegt mit einem Source-Folder "classes_AS2". Darin wollte ich jetzt als erstes ein paar Decorator for die Window-Componente von Flash erstellen. Sollte ich da zum beispiel das Paket gleich benenne wie das der Komponente? Ich würde also die Klasse "mx.containers.WindowDecorator" erstellen? Oder doch lieber in einem weiteren Package als "mx.containers.window.WindowDecorator"? Das fände ich z. B. schöner. Oder ratet Ihr ab davon, die gleichen Pakete der Komponenten zu verwenden?

Gibt es gängige Verfahrensweisen wie man Klassenbibliotheken strukturiert? Ich habe bis jetzt nur erfahren, dass man für die Projekte Domainstruktur abbildet. Also z. B. das Paket "com.derraab.PROJEKTNAME".

Naja, viele Fragen...

[Omega Psi]

• Packages klein schreiben
• Packages nicht wie Klassen nennen.

[Janoscharlipp]

Auf jeden Fall solltest du die Klasse in deine Package-Struktur packen, nicht in die mx-Struktur von Macromedia. Sonst könnte es ja irgendwann passieren, dass die auch nen Window-Decorator anlegen, und dann hast du zwei Klassen mit gleichem Package und gleichem Namen.

[Omega Psi]

Wenn es noch andere Sub-Packages gibt, kann man die aber eindeutig identifizieren.

[klickverbot]

Als Anregung (oder abschreckendes Beispiel? ) hier die Struktur meiner Codebase (bzw. Klassenbibliothek):

Mein Root ist at.klickverbot. Auch wenn ich diese Domain (noch) nicht besitze, sollte das doch eindeutig sein.

In diesem Root existieren verschiedene Pakete für die "Subsysteme", also beispielsweise drawing für die Zeichenfunktionen, ui für die Benutzerschnittstelle, oder util für Sachen wie Timer, EnterFrame, Delegate, ...
In diesen Paketen liegen im Normalfall die Klassen, aber manchmal ist eine feinere Einteilung erforderlich. Beispielweise habe ich in at.klickverbot.ui noch ein Unterpaket namens themed, dass die Klassen enthält, die mein Theme-System verwenden.

Projekte bekommen ihr eigenes Root-Paket at.klickverbot.projektname, wenn es die Logik erfordert – beispielsweise bei MVC – werden auch diese noch einmal unterteilt.


Ich würde auf gar keinen Fall eigene Klassen im mx-Namespace erstellen. Abgesehen davon, dass hier mit einer neuen Flash-Version neue Klassen hinzukommen können, wird dies die meisten Leute verwirren, die das Vergnügen haben, deinen Code lesen zu müssen.

[derRaab]

@Omega Psi: Die Schreibweisen sind mir klar, wollte es nur hervorheben.

Also dann mache ich das jetzt in Zukunft so:

Kundensachen lege ich also in einem Paket
"topleveldomain.domain"
ab und erstelle darin die projektspezifischen Klassen.

Zusätzlich habe ich dann noch eine separate Bibliothek in der ich allgemeingültige Klassen hinterlege wie z. B. String Validatoren usw...
Die liegen dann in meinen Paket
"com.derraab".
Die will ich ja wiederverwenden...

So. Oder?

[Omega Psi]

Yoar, c'est very vernünftig.

[derRaab]

Und mein WindowDecorator liegt dann halt genau da:

"com.derraab.mx.containers.window.WindowDecora tor"

[Omega Psi]

Hm, also im endeffekt ist es echt latte, wo du das Ding speicherst... aber wieso mx? Also, du mir ists egal... ob du

• "com.derraab.mx.containers.window.WindowDecora tor"

oder auch

• "com.derraab.containers.window.util.WindowDecorato r"

benutzt.

[derRaab]

mx nur, damit klar ist, dass es sich um Erweiterungen des mx-Paketes von Macromedia ist. Huch, Adobe mein ich.

[Smocoe]

Ich tendiere eher dazu projektspezifische Klassen mit in den Projektordner zu legen (Projektordner_flash/Classes).
Zum einen sind dann alle Entwicklungsdateien zusammen, was Weitergabe und Backup erleichtert, zum anderen möchte ich nicht auf die Idee kommen, diese Klassen für spätere Projekte des Kundens umzuschreiben, so dass das andere Projekt nicht mehr damit läuft.

Projektübergreifende Klassen speichere ich natürlich auch in der von dir genannten Form ab. Zu Beachten ist dabei aber, wenn Änderungen an diesen Klassen vorgenommen werden, können evtl. ältere Projekte nicht mehr veröffentlicht werden, da diese die alte Schnittstelle verwenden.

Wenn ich Änderungen vornehmen, kopiere ich stets alle Klassen in einen neuen Versionsordner und arbeite damit weiter. Die Projekte erhalten dann einen Vermerk mit welcher Version des Frameworks sie veröffentlicht wurden. Mit Subversion wäre das ganz sicherlich noch eleganter zu lösen.

Wollte ich nur noch zu bedenken geben.

[klickverbot]

Zitat von Smocoe

Ich tendiere eher dazu projektspezifische Klassen mit in den Projektordner zu legen (Projektordner_flash/Classes).

Das mache ich genauso – vor allem deswegen, weil ich dann alles komfortabel auf einmal ins SVN-Repo hochladen kann.

Ich glaube aber, das macht hier jeder so...

[Smocoe]

Zitat von derRaab

Kundensachen lege ich also in einem Paket
"topleveldomain.domain"
ab und erstelle darin die projektspezifischen Klassen.

weiß nicht ob er damit die selbe ordnerstruktur für alle anderen klassen gemeint hat oder nicht, habe es nur deshalb nochmal erwähnt...

[derRaab]

Ich wollt nur noch kurz klarstellen, dass ich alle Kundenspezifischen Klassenpakete natürlich im Workspace des Kundenprojektes habe. Und zusätzlich eine allgemeingültige Library als eigenständiges Projekt, die ich dann als LinkedLibrary und über den Klassenpfad in der FLA einbinde.

Vielleicht sollte ich auch einfach immer dieses Paket zusätzlich in den Projektordner packen. Ich würde halt nur ungern allen Kunden immer meine komplette Bibliothek überlassen. Dann kopier ich halt nur das, was ich gerade benötige rüber.