wie managed ihr eure packages?

[bruce_wayne]

hallo,

setzt man ein grösseres projekt mit MVC oder ähnlichen mustern um fallen ja schnell mal ziemlich viele klassendaeien an, die es gilt geschickt in packages zu gliedern.

wie handelt ihr das?

mein gedanke:

- core.mvc (basisklassen, von denen controller und view erben)
- core.data (basisklassen für die speicherung von datenstrukturen)

- ui (views)
- controls (controllers, listener, events, etc)
- data (model, xmlparser, etc)
- lang (sprachswitch)
- utils

[Omega Psi]

Das ist so schon ok.

[Sir Freako]

Noch mehr Überblick hätte man so :

projekt.core.View : UI

projekt.core.Model.listeners : listener, events (die Event Listener höhren ja nur darauf was der Controller so macht also gehören Sie meiner Meinung nach ins Model / Listener == Observer > rooting

projekt.core.Model.utils
projekt.core.Model.lang
projekt.core.Model.data

projekt.core.Controller.controller

und dann halt auf alles adaptieren

projekt.modul.Model
projekt.modul.View
projekt.modul.Controller

da ist dann gleich onSteam (ihr kennzes scho's Stückerl)

thats funny omega Psi

[hazy fantazy]

Die Frage ist: Was ist ein package überhaupt?
Ist es eine Art Metaklasse, also die Klassen eines Packages bilden eine gemeinsame Funktionalität ab, z.B. ein package compiler hat die Klassen Scanner, Parser, Generator?
Oder ist es eher eine Organisationshilfe, wie z.B. ein package events, das alle Subklassen von Event enthält, ein package command, das alle Subklassen von Command enthält, usw.

[Janoscharlipp]

gute Frage, hazy fantazy
Bin jetzt irgendwie verwirrt, ich glaube bisher hab ich das immer so gemacht, wie es eben passte, aber nicht konsequent, sondern mal so, mal so.

Zum eigentlichen Problem:
ich würde einzelne Packages für View, Model und Controller machen, das kann nicht schaden, und sorgt für Übersichtlichkeit, wenn es dann mal viele Klassen werden.

[:: RK ::]

Zitat von hazy fantazy

Die Frage ist: Was ist ein package überhaupt?
Ist es eine Art Metaklasse, also die Klassen eines Packages bilden eine gemeinsame Funktionalität ab, z.B. ein package compiler hat die Klassen Scanner, Parser, Generator?
Oder ist es eher eine Organisationshilfe, wie z.B. ein package events, das alle Subklassen von Event enthält, ein package command, das alle Subklassen von Command enthält, usw.

hi,
also ich bin folgender Meinung, was Packages angeht:
wenn man sich mal den SourceCode von PaperVision3D anschaut, dann
sieht man doch recht gut, wie das mit dem Packages gemeint ist. Es gibt
merhere Unterverzeichnisse (Ordner) im Projektverzeichnis:

• cameras
• components
• core
• events
• materials
• objects
• scenes
• utils

Jedes Verzeichnis beinhaltet nun mehrere Klassen:
Z.B. das Verzeichnis "objects":

• Plane.as
• Spere.as
• Cylinder.as
• Cubes.as
• etc...

schaut man sich bsplw. "Plane.as" an dann steht da folgendes:

package org.papervision3d.objects
{
  [...]
  public class Plane extends TriangleMesh3D
  {
    [...]
  }
}

In der "Sphere.as" Datei steht dieses drin:

package org.papervision3d.objects
{
  [...]
  public class Sphere extends TriangleMesh3D
  {
    [...]
  }
}

Also die eigentlichen Klassen "Plane" und "Sphere" sind beide Bestandteil des
Packages "objects". Es gibt jedoch keine "Packages" Datei die irgendwelche
Bestimmungen beinhaltet. Es ist eher eine Organisationshilfe für den
Programmierer, damit er später weiß welche Klasse was macht und zu wem
gehört. Aber ich denke es hat keinen programmiertechnischen Einfluss.

[Janoscharlipp]

Bei Papervision sind die Klassen nach ihren Basisklassen in Packages geordnet. Klasse X erbt von Klasse Y? Ab in package y mit Klasse X.
Das utils-Package hingegen ist eine Sammlung von Klassen, die nichts im Vererbungspfad miteinander gemein haben, wenn man die Namen ansieht, würde eigentlich alles für ein interactivity-Package sprechen, sie wurden aber einfach in "utils" gepackt. Ist also auch nicht unbedingt ein Musterbeispiel in meinen Augen.

[Omega Psi]

Zitat von hazy fantazy

Die Frage ist: Was ist ein package überhaupt?
Ist es eine Art Metaklasse, also die Klassen eines Packages bilden eine gemeinsame Funktionalität ab, z.B. ein package compiler hat die Klassen Scanner, Parser, Generator?
Oder ist es eher eine Organisationshilfe, wie z.B. ein package events, das alle Subklassen von Event enthält, ein package command, das alle Subklassen von Command enthält, usw.

Ist das von dir eine rethorische Frage? Packages sind nichts anderes als Namensräume, wie du weisst. In Java werden diese ja oft nach Domain/Projekt/Funktionalität getrennt.

Ich persönlich verwende Namen nicht nach MVC Konventionen (falls es dafür Konventionen geben sollte) auch wenn es nicht Schaden kann. Wenn ich einen reine Feed API baue ist es klar, dass es nur Model + Controller gibt etc.

@freako was ist funny?

[hazy fantazy]

Nein, rethorisch ist die Frage nicht. Ich glaube, die Frage nach der optimalen Packagestruktur ist eine Optimierungsfrage. Verschiedene Kriterien muessen gegeneinander abgewogen werden. Die Entscheidung hängt letztlich von vielen Faktoren ab, wie z.B. persönlichen Vorlieben, Groesse des Teams, Unterstützung durch die IDE, etc.
Wenn ich klassisch mit Cairngorm arbeite, verteile ich die Klassen in verschiedene Packages, Events in das eine, Commands in ein anderes, Models in ein drittes und Views in ein viertes Package. Wenn diese Klassen jedoch immer zusammen benutzt werden, würde ich sie eher in "ein" Package stecken, als sie ihrer Art gemäß zu verteilen.

Gibt es noch andere Kriterien als diese? Also Package zur Organisation einer Einheit (alle Motorteile in ein Package) oder zur Organisation einer Art von Dingen (Muttern in ein Package, Unterlegscheiben in ein anderes). Package zur Vermeidung von Namenskonflikten fiele mir noch ein.

[Omega Psi]

Nun ja, Namespaces nannte ich ja schon und das finde ich nach wie vor auch am wichtigsten da ich die Benennung der Klassen für tendenziell wichtiger halte (sie Baum vs XML).

In einen Java Projekt habe ich mit verschiedenen packages gearbeitet um auto-generierte Stub- und Service-Klassen von meinen eigenen zu trennen. Diese erbten oder/und implementierten die Interfaces/Klassen. Hinterlegt habe ich diese in ./client/impl und ./service/impl um ServiceStubs und Service-Implementierungen trennen zu können. Hatte ausserdem den Vorteil, dass ich packages leichter verwalten konnte, falls ich die auto-generierten packages löschte und ein Refaktoring meiner XML Schemata durchführte. In dem Fall war meine Wahl zusätzlich zum Namensraum und der Trenneung von Funktionalitäten von packages (bzw. der enthaltenden Klassen) auch rein pragmatisch.