Paket und Software Design Fragen.

[Fabeltier]

Hallo,
Ich habe einige Fragen zu den Packages die es in Java gibt und dem Design das man bei der Entwicklung anwenden sollte.

1. Wie sollte das Konzept der Packages planerisch verwendet werden, bzw wie wird es sinnvoll angewandt?

2. Ich habe ein mittleres Projekt (ca 50 Klassen), welches von den Paketen her, wie ich finde, mit einiger Unsicherheit von mir angelegt wurde. Dh teils habe ich diese nach Aufgaben (bspw Fileoperationen, Berechnungen, etc) teils nach "Klassentyp" (Dialoge, Documents, besondere Panels, ...) erstellt. Mittlerweile habe ich ca 6 Pakete, eines davon enthaelt nur 2 Klassen, ein anderes ca 20.

3. Gibt es da Faustregeln wieviele Pakete bei wievielen Klassen und wieviele Klassen durchschnittlich pro Paket?

4. Ich denke bei einem ausgewogenen Design, sollten alle Pakete wohl ca gleich viele Elemente enthalten, oder?

5. Sollte man eher mehr oder weniger Pakete erstellen - wieviele waeren bspw fuer ein 50 Klassen Projekt angebracht?

6. Sollte man generell alles eher in ein Paket reinhauen oder die Pakete nach Typen (zB Dialoge, Frames, Panels, Listen, ...) strukturieren oder aber nach der Aufgabe der jeweiligen Klassen im Programm selber (bspw. Haupt frame und panels, Fileoperationen, Tabelle mit Model etc, Hauptdatenliste,...) aufteilen?

7. Was ist der Zweck von Paketen, bzw auf welcher Ebene setzt man Pakete zum Kapseln des Codes ein?

Bin da mom etwas ratlos, aber sicherlich gibt es da vernuenftige Ansaetze, damit man dieses Kraut und Rueben vermeidet..

 

[Ralf1007]

Da Dir die Pakete eine Ordnerstruktur anlegen, die du dann im Explorer auch sehr schön erkennen kannst, solltest du dementsprechend auch deine Package-Struktur aufbauen. Wieviele Klassen nun in einem Package liegen, ist meiner Meinung nach nicht so wichtig, hauptsache es entsteht eine Struktur mit der du arbeiten kannst. Mal auf dein Projekt bezogen, könntest du eventuell eine ähnliche Paketstruktur anlegen wie folgende:

- deinProgramm.model.Fileoperationen (hier alles zu Operationen mit Dateien rein)
- deinProgramm.model.Berechnungen (alle zugrundeliegenden Berechnungen)
- deinProgramm.graphic.panel
- deinProgramm.graphic.dialogs
- deinProgramm.graphic.....

Also wichtig ist immer eine strikte Trennung zwischen Funktionalität(deinProgramm.model.*) und grafischer Oberfläche bzw. Repräsentation (deinProgramm.graphic.*). Ob die Namen von mir so gut gewählt sind, sei dahingestellt. Wenn du nun z.B. die Dialoge noch unterteilen kannst, weil sie in verschiedene Gruppen gehören, dann solltest du das natürlich auch noch machen. Durch diese Art der Paketstruktur findest du, wenn du sie so logisch anlegst später deine Klassen wesentlich einfacher wieder.

Ich hoffe ich konnte Dir helfen.

MfG Ralf

 

[Fabeltier]

Danke,

Das mit der strikten Trennung von grafischer Repraesentation und Funktionalitaet im Hintergrund ist so eine Sache. Natuerlich habe ich versucht die Funktionalitaet des Hauptframes und seinen Widgets soweit mit einem Hauptkontrollobjekt, das zur Steuerung im Hintergund und zur Interaktion mit anderen Klassenobjekten fungiert zu trennen. Dialoge, Panels, Tabbs fuer ein Tabbed pane und aufwendiger Actionlistener sind jeweils als eigene Klassen von entsprechenden (oft als abstrakt angelegten) Sammeltyp-Klassen, abgeleitet worden, nur so einfach liessen sich diese Hintergrundklassen nicht von der Grafischen Oberflaeche trennen.

IdR kommt es mir oft so vor, als wenn man viel leichter die Grafik abspalten koennte und man die Funktionalitaet dessen einfacher austauschen koennte, als bspw zur Funktionalitaet eine andere Grafik davor setzen - ist das ein Fehler in der Konzeption oder ist eine grobe Trennung von Funktionalitaet und Grafik ausreichend?

Ich weiss, das es hier eher um Spitzfindigkeiten geht, aber eben auch um ideale Zielsetzungen, die vllt fuer den Benutzer, der schnell was lauffaehiges haben will absolut wurscht sind. Aber andererseits sind das Fragen mit denen ich bei jedem Java Projekt immer wieder neu konfrontiert bin. Ich habe auch den Eindruck das Java die grafische Planung sehr beguenstigt und eine leichte _Ab_trennung dieser gar nicht so relevant ist. Da man in Java recht komfortabel bei sehr kleinen Dingen auch komplett nur die grafische Ebene ausimplementieren kann. Taeuscht das?

 

[Ralf1007]

IdR kommt es mir oft so vor, als wenn man viel leichter die Grafik abspalten koennte und man die Funktionalitaet dessen einfacher austauschen koennte, als bspw zur Funktionalitaet eine andere Grafik davor setzen - ist das ein Fehler in der Konzeption oder ist eine grobe Trennung von Funktionalitaet und Grafik ausreichend?

Ich bin selber noch nicht allzu lange dabei aber ich mache etwas ähnliches wie du und bei mir ist es so, dass die grafische Oberfläche einfach auszutauschen ist, da auf dieselben Schnittstellen zugegriffen werden kann. Es entstehen aber Probleme dabei eine andere Funktionalität dahinterzulegen und die Grafik zu behalten, denn die Zugriffe der grafischen Oberfläche auf das zugrundegelegte Modell sollten ja nicht verändert werden, sodass du bei jeder anderen Funktionalität dieselben Schnittstellen bereistellen musst. Also um deine Frage zu beantworten: Wenn du wirklich perfektionistisch arbeiten willst, dann schreibst du Interfaces, die unabhängig vom Modell bzw. der Grafik sind und das Modell und die Grafik implementieren diese egal in welcher Lesart, so kannst du nämlich dann auch beide austauschen und musst lediglich auf die Schnittstellen zugreifen. Allerdings finde ich, dass das sehr aufwendig ist, aber bei großen Projekten im Grunde auch unerlässlich. Am allerbesten ist es, wenn du es von Vornherein so planst, was du ja leider versäumt hast, denn im Nachhinein diese Änderungen zu machen ist unglaublich viel Arbeit.
Du hast auch was von abstrakten Klassen geschrieben und so verkehrt ist das auch nicht. Der Eindruck, dass das Austauschen nicht so einfach möglich ist, entsteht dadurch, dass es noch nicht perfekt ist.

Da man in Java recht komfortabel bei sehr kleinen Dingen auch komplett nur die grafische Ebene ausimplementieren kann. Taeuscht das?

Ich sehe das ähnlich.

 

[alehandro]

4. Ich denke bei einem ausgewogenen Design, sollten alle Pakete wohl ca gleich viele Elemente enthalten, oder?

tuest Du programmieren oder Symmetriekunde betreiben? Das ist Wurscht wieviel Elemente Deine Packages enthalten, solange sie Dir eine gute logische Trennung der Klassen und ein schnelles Zurechtfinden erlauben

5. Sollte man eher mehr oder weniger Pakete erstellen - wieviele waeren bspw fuer ein 50 Klassen Projekt angebracht?
6. Sollte man generell alles eher in ein Paket reinhauen oder die Pakete nach Typen (zB Dialoge, Frames, Panels, Listen, ...) strukturieren oder aber nach der Aufgabe der jeweiligen Klassen im Programm selber (bspw. Haupt frame und panels, Fileoperationen, Tabelle mit Model etc, Hauptdatenliste,...) aufteilen?

Das mit dem Pakete-Erstellen werde ich nicht ins Unendliche treiben wollen. Die Übersicht geht verloren.

7. Was ist der Zweck von Paketen, bzw auf welcher Ebene setzt man Pakete zum Kapseln des Codes ein?

Übersicht und Trennung ... Kapseln: schön ist wenn pakete möglichst wenig von einander wissen. Sprich es ist immer eine gute Idee Subpackages mit Fassaden(die die Schnittstelle zum Package sind) zu versehen, solange das natürlich überhaupt möglich ist.

 

[Fabeltier]

Na gut, ich habe ja auch nicht einfach drauf losprogrammiert sondern immer versucht etwas zu planen, kapseln und Modelle zu verwenden. Allerdings eben auch mit prioritaeten. bspw habe ich mehrere Arten von tabbed Pages auf die ich etwas mehr Eingegangen bin als bspw auf andere Dinge. Also Interfaces und v.a. abstrakte Klassen (da ich eig. nicht von Java her komme, bin ich dieses Konzept etwas mehr "gewoehnt") habe ich benutzt, aber eben auch nur da wo es imo notwendig war.

Beim abkapseln der Grafik von der Funktion frage ich mich teilweise schon ob das ueberall so unbedingt sinnvoll ist, oder einfach nur einen Mehraufwand darstellt, der gerade mit den in SWING moeglichen L&F's nicht unbedingt notwendig ist. Ich denke eine Umstellung von bspw SWING auf SWT, waere sicherlich eine andere Sache. Allerdings nutzt das Prg ja schon auch Vorzuege von Swing und diese nicht zu nutzen, dafuer aber eine Perfekte Kapselung zu erreichen (wenn man sowieso nie vorhat das Ding jemals auf SWT, AWT oder sonst was zu uebertragen) halte ich nicht unbedingt fuer soo sinnvoll - bin aber gespannt wie andere das sehen und wuerde mich auch gerne ueberzeugen lassen?

So gesehen, finden die vorzuege der Grafik schon auch nur in Grafikrelevanten Klassen statt, was jedoch definitiv keine Grafik mehr darstellt sind lediglich Fileoperationen, Berechnungen und Listenverwaltung). Ansonsten ist bspw eine Kontrollklasse der Grafik schon sehr stark damit verwoben und dort eine zusaetzliche Layer einzufuegen fuer Auswechselbarkeit.. hm, es liesse sich nun schon rel. einfach realisieren, aber die Probleme lagen eig. schon auch woanders. Bei der Uebersichtlichkeit stimme ich absolut zu.

Mir geht es jetzt einfach nur noch mal darum evtl der Paketstruktur den letzten Schliff zu geben, was sich ja einfach durch rumschieben realisieren laesst. Ich werde wohl auch mal in den UML Diagrammen nachsehen, wie die Klassen miteinander verwoben sind und was sich da noch kapseln laesst.