[JAVA] Instanzen Registrieren und drauf zugreifen

[chetigol]

Hi!

Ich arbeite mich gerade in Java ein und habe eine frage zum folgender Broblemstellung:

Ich möchte beim Erstellen der Objekte einer bestimmten Klasse, diese in einer Liste Registrieren. Diese Liste wird dann in einer anderen Klasse verwendet, wie sollte so etwas in Java am besten gelöst werden? Mein Ansatz ist derzeit folgender:


public class Objekt1 {
static private Map<Integer, Objekt1> Liste = new HashMap<Integer, Objekt1>();


public static getObject( int Id ){

return( Liste.get(Id) );
}

Objekt1( int id )
{
Liste.put( id , this );
}

}


Dieses Instanzen dieser Klasse werden irgendwo erstellt

new Objekt1(1);
new Objekt1(2);
new Objekt1(3);


Dabei werden die Objekte in die Liste Aufgenommen! Jetzt wird aus einem komplett anderen Objekt auf diese Liste zugegeriffen:

public class ObjektXY {
// .......

void verwendeObjekt(){
Objekt1.getObject( 1 );
}

}

Ist an dieser vorgehensweise etwas auszusetzen? Die Liste wird ja als eine Art globaler Variable verwendet! Ist es in Java auf diese Art ok?
Oder sollte ich die Liste in ein eigenes Objekt ausgliedern und dieses dann dem „ObjektXY“ in einem Konstruktor übergeben, damit dieses Objekt auf die Liste zugreifen kann????

Also als Beispiel:

o1 = new ObjektXY( Objekt1.Liste );


Oder wie schon oben beschrieben, die Liste in ein eigenes Objekt ausgliedern, welches die „Objekt1“ – Instanzen aufnimmt, und dieses an ObjektXY übergeben??

Ich tendiere eher zur ersten Möglichkeit, aber so sicher bin ich mir da auch nicht!

[Monger]

So jetzt ganz ohne konkretes Beispiel wird das eine abstrakte Diskussion...

Die erste Frage wäre: warum ordnest du überhaupt jedem Objekt eine ID zu? Jedes Objekt HAT ja eine eindeutige Identität. Wenn du

Object o = new Object();

schreibst, stehen ja in Wahrheit auf der linken und rechten Seite der Gleichung nicht das Objekt selber, sondern dessen Identität. Im Endeffekt ist das irgendeine Nummer aufm Objekt Heap der Java VM.

Zweitens: wie genau sieht denn die Beziehung zwischen deinem ObjektXY und dem Objekt1 aus? Ist es ein integraler Bestandteil, oder hat es nur eine lose Beziehung?
Gern verwendetes Beispiel: ein Auto ist kein Auto ohne Räder und Türen, deshalb müssen diese Dinge als Attribute der Autoklasse modelliert werden.
Auf der anderen Seite: ein Auto hat zwar eine Beziehung zur Straße, definiert sich aber nicht dadurch. Ein Auto ist auch auf einem Feldweg immer noch ein Auto.

Ob jetzt also deine Sammlung an Objekten irgendwo frei im Raum quasi als globale Konstante steht, oder nur im Kontext von irgendwas anderem existieren kann, kommt schlicht auf den Anwendungsfall an.
Stell dir folgende Frage: kannst du mit deinem ObjektXY etwas anfangen, ohne dass es mindestens ein Objekt1 hat? Wenn nein, wäre es möglicherweise eine gute Idee, die korrekte Initialisierung dieses Objektes über einen passenden Konstruktor zu erzwingen.

[chetigol]

Ok, versuch ich mal mit einem konkreten Beispiel! Es handelt sich dabei um einen Prametergenerator für ein System mit über 50 Parameterarten. Dabei sollen alle Parametertypen und Generatoren möglichst generisch und unabhängig voneinander gebaut werden.

1. GeneratorCore – Beispiel:

// eigene Core - Klasse, an welche von außen eine Liste der zu erzeugenden Parameter übergeben wird
GeneratorCore( ListParameter2Generate[] )

// parameterliste durchlaufen und records generieren
for(...){
// holt sich aus der statischen Klassenliste den entsprechenden Generator
Generator gen = Generator.getGenerator( ListParameter2Generate[i].paramId )

// generiert den Record!
gen.generate( ParameterDescription.getDescription( ListParameter2Generate[i].paramId), stream );
}


2. Die ParameterDescription
Jeder Parametertyp enthält eine PAraemterdescription, welche dem Generator bestimmte zusatzinformation mitteilt! zB, soll der Parameter komprimiert werden, was für einen Parametertyp es sich handelt,...

Ein Beispiel für eine Parameterdescription:


// eine abstracte Parameterdescription - klasse, von der jede weitere Parameterklasse abgeleitet wird und seine eigenen eigenschaften hinzufügt.
// im konstruktor dieser klasse wird beim instanzieren jedes parameterobjekt in die liste aufgenommen

abstract ParameterDescription{
static List<Parameter> parameter;

static Parameter getParameter( paramId );

protected ParameterDescription( .... ){
parameter.add( kennung, this );
}

}

// Spezifischer Parameter 1
static class SystemXYParameter extends ParameterDescription{

// subkennung, gilt nur für parameter des Systems XY
public byte subkennung;

// Parametertyp (Gilt nur für SystemXY)
public boolean common;

public SystemXYParameter( int kennung, int size, byte subkennung, boolean common ){
super( kennung, size );

this.subkennung = subkennung;
this.common = common;
}
}



3. Die Generatoren:
für jeden Parametertyp wird ein (oder mehrere) generatoren definiert


// Definition der Generatorklassen
// Abstrakte Generatorklasse oder Interface
abstract class Generator{

// im construktor wird ein generator automatisch in die Liste eingefügt
static List<Parameter> generators;

// liefert einen generator mit der kennung id zurück
static getGenerator( int id ) {
return( List.get(id) );
}

public abstract void generate( ParameterDescription parameter, OutputStream out );
}


// 1. Generatoren für Parameter des SystemXY

class GeneratorSystemXYSubPar1 extends Generator{

@Override
public void generate(ParameterDescription parameter, OutputStream out ){
PrintStream data = new PrintStream(out);

// schreibe Parameterstruktur in den Stream
//....

//1. zugriff auf die members der super - Klasse
data.print( parameter.kennung );
data.print( parameter.size );
// 2. zugriff auf die erweiterten Parameter fürs SystemXY
data.print( parameter.subkennung );
data.print( parameter.common );

// 3....schreibe eigentliche parameterdaten ( aus Database, File,...je nach generator)
}
}



4. Initialisiert wird das ganze, indem beim Powerup die Objekte erzeugt werden:

new PAraemterXY( 1, .....);
new GeneratorXY( 1, ...);

new PAraemterZ( 2, .....);
new GeneratorZ( 2, ...);



Zugegriffen wird also im Core über die statischen get-Funktionen auf die Listen!
Jetzt gibt es aber noch einen Parameter, der alle vorhandenen Parameter in ein Binärfile inkl einiger eigenschaften ins file schreibt.
Es gibt also einen Generator dafür:



class ParameterListGenerator extends Generator{

@Override
public void generate( ParameterDescription parameter, OutputStream out ){
//........
for ( i = 0;....i++) {
p = ParameterDescription.getParameter( i );
// schreibe daten von p
}
}
}



Was haltet Ihr von diesem Konzept? der Zugriff auf die statischen Listen der ParameterDescription und der Generator - Klassen ????

[Ectoplasma]

Irgendwie erinnert mich das Konstrukt an einen endlichen Automaten. Aber so hundertprozentig bin ich mir bei deinem Ansatz nicht sicher. Ich meine du solltest mal beschreiben, was denn genau die Engabedaten sind, wie diese dann verarbeitet werden und was hinten herauskommen soll. Deinen Code verstehe ich noch nicht so wirklich, weil die eigentliche Aufgabenstellung daraus nicht so einfach abzuleiten ist,

[chetigol]

hab mir schon gedacht, dass es nicht so einfach wird...hehe!

Also, der Einstiegspunkt ist der GeneratorCore! An diesen wird eine Liste mit ParameterIds übergeben, welche erzeugt werden. Die Parameter, die erzeugt werden sind zu 90% binärdaten für ein Embeded-System und werden als file Übertragen.

Also:

ParameterX --> GeneratoreCore --> GeneratorCore sucht nach einem passenden Generator für ParameterX --> wenn gefunden, wird die "generate( Stream )" funktion des generators aufgerufen.

Es soll deshalb so gelöst werden, da für den Core egal sein soll, wie die daten in den Stream geschrieben werden und wo der einzelne Generator die daten hernimmt (Datenbank, Files,... ).

Der Paraemter mit der Kennung "1" wird zum Beispiel in ein Binärfile geschrieben, wird aber plötzlich verlangt ihn als XML zu schreiben, brauch ich nur einen neuen Generator für ein und den selben Parametertyp zu installieren

// installiert eine Binärgenerator für den Parameter 1
new GeneratorParameter1Bin( 1, ..... )
//....
// holt sich den Generator für Record 1 und erzeugt ihn
Generator.getGenerator( 1 ).generate( stream );

// ... überschreibt den Binärgenerator mit einem XML-Generator
new GeneratorParaemter1XML(1,....);
//....
// holt sich den aktuell insallierten Generator für Record 1 und erzeugt ihn
Generator.getGenerator( 1 ).generate( stream );

[Monger]

Wenn du einen GeneratorCore hast der Parameter analysieren und damit dann irgendwelche Ergebnisse generieren soll, ist es imho plausibel dass dieser GeneratorCore auch seine Generatoren verwaltet.
Ich stelle mir den grundsätzlichen Ablauf ungefähr so vor:

- der GeneratorCore kriegt eine Liste an Parametern
- Er schaut sich die Parameter an, und analysiert anhand irgendeines Parameters was damit zu tun ist
- Er holt sich den passenden Generator, und übergibt ihn den passenden Parameter.

Ich hab gesehen, du hast irgendwo in den Parametern so ein Kennungsfeld. Ist das genau dafür da? Wieso dann nicht eine bestimmte Kennung mit einem bestimmten Generator verknüpfen?

Map<byte, Generator> m = new HashMap<byte, Generator>();
m.add(1234, new GeneratorXY); // etc.

// ...

Parameter p;
byte Kennung = p.Kennung;
Generator g = m.get(Kennung);
g.machSonstwas(p);

[Tiamat]

Also sowas macht man eigentlich immer auf dem zweiten Weg.

Du hast eine Klasse, die eine Collection beinhaltet und damit möchtest du eine spezielle Funktionalität für außenstehende Klassen z.b ermöglichen.

Beispiel Stack,Queue, Cache ..

Jetzt möchte irgendeine Klasse dieses Object nutzen.

Möglichkeit 1: Die Klasse verwaltet ein Objekt deiner Klasse

Möglichkeit 2: Es wird an x-beliebiger Stelle im Projekt GENAU DIESES Objekt benötigt.

Dann musst du jede x-beliebige Methode, die dieses Objekt nutzt, mit einer entsprechenden Referenz als Parameter ausstatten.(Call by Reference)

Alternativ zu 2: Zugriff auf die Daten per statischem Zugriff.

Dieses Konstrukt ganz oben erzeugt bei mir ein ziemlich schlechtes Bauchgefühl.

[Monger]

Dann musst du jede x-beliebige Methode, die dieses Objekt nutzt, mit einer entsprechenden Referenz als Parameter ausstatten.(Call by Reference)

Es gibt kein Call by Reference in Java!
*SCNR* :D

[chetigol]

Genau, die Kennung ist die Parameterkennung!
An soetwas hab ich auch schon gedacht! dass der Core die Liste der Generatoren verwaltet. Müsste dann den Core dann aber so erweitern, dass die Generatoren von "außen" installiert werden können. Also eine funktion:

GeneratorCore.installGenerator( 1234, new GeneratorXY() );

Was soll ich jetzt aber mit der PArameterDescription machen? Diese enthält nämlich Daten, die für die Generatoren wichtig sind.
Mein erster Ansatz war, dass ich dem jeweiligen Generator im konstruktor die Parameterdescription übergebe:


GeneratorCore.installGenerator( 1234, new GeneratorXY( new Parameter1Desc() ) );


soweit, so gut! Das Problem ist, dass ein bestimmter Generator die Daten aller Description in ein File schreibt! Also brauche ich eine Liste mit diesen ParameterDescriptions. Deshalb der Ansatz mit der statischen Liste:


abstract ParameterDescription{
static List<Parameter> parameter;

static Parameter getParameter( paramId );

protected ParameterDescription( .... ){
parameter.add( kennung, this );
}

}

so kann jetzt ein Generator diese Liste durchgehen ( ParameterDescription.getParameter(i) ) und die Daten ins File schreiben.


--> Der Nachteil des ganzen ist aber folgender:

Es wird ein neuer Generator und ein neuer Parameter für die Kennung 1234 erzeugt. GeneratorXY referenziert das Objekt "Parameter1Desc(1234, 1, 2)" und in der Liste "ParameterDescription.List" wird für die ID 1234 das Parameter-Objekt Parameter1Desc(1234, 1, 2) eingetragen.


GeneratorCore.installGenerator( 1234, new GeneratorXY( new Parameter1Desc(1234, 1, 2) ) );


Was ist, wenn jemand "versehentlich" einen Parameter mit der gleichen Kennung mit anderen Daten erzeugt!


// Parameter 1234 wird erneut mit anderen Daten erzeugt
// wesetzt damit in der Liste "ParameterDescription.List" die zuvor erzeugten ParameterDescription
new Parameter1Desc(1234, 5, 6)


Jetzt greift der GeneratorXY auf ein anderes Objekt zu (Parameter1Desc(1234, 1, 2) ) , als welches in der Liste "ParameterDescription.List" eingetragen ist. -> Wodurch eine Inkonsistenz entsteht!

-> Lösung: Der Generator bekommt das PArameterobjekt erst zur Laufzeit aus der Liste übergeben, und nicht schon beim konstruieren! So greift er immer auf ein "gelistetes" Objekt zu!

Die frage ist nur, wo implementiere ich diese Liste? Global in der ParameterDescription - Klasse (wie oben)?? Dann muss ich über den Globalen Zugriff "ParameterDescription .getParameter()" drauf zugreifen????

[chetigol]

Also sowas macht man eigentlich immer auf dem zweiten Weg.

Du hast eine Klasse, die eine Collection beinhaltet und damit möchtest du eine spezielle Funktionalität für außenstehende Klassen z.b ermöglichen.

Beispiel Stack,Queue, Cache ..

Jetzt möchte irgendeine Klasse dieses Object nutzen.

Möglichkeit 1: Die Klasse verwaltet ein Objekt deiner Klasse

Möglichkeit 2: Es wird an x-beliebiger Stelle im Projekt GENAU DIESES Objekt benötigt.

Dann musst du jede x-beliebige Methode, die dieses Objekt nutzt, mit einer entsprechenden Referenz als Parameter ausstatten.(Call by Reference)

Alternativ zu 2: Zugriff auf die Daten per statischem Zugriff.

Dieses Konstrukt ganz oben erzeugt bei mir ein ziemlich schlechtes Bauchgefühl.

ja, ich fühle mich auch nicht ganz so wohl dabei, deshalb schreib ich ja hier :biggrin:!
Monger hat mich jedenfalls schon überzeugt, die Generatoren in den Core zu integrieren, wo ich die ParameterDescription - Liste aber paltziere, dessen bin ich mir nicht sicher :confused:
Muss mir noch was überlegen! vielleicht Parametriere ich den Core mit einer Instanz dieser Liste???


ParameterDescriptions pars = new ParameterDescriptions;

pars.add( new Parameter1(1234, 1 ,1) );
pars.add( new Parameter2(133234, 3 ,1) );
....

// start Core
core = new GeneratorGore( pars );

// install Generators
core.addGenerator( new Generator1(1234, .... ) );
core.addGenerator( new Generator2(133234, .... ) );
....

[Monger]

Ist denn die Parameterdescription nicht eigentlich eine Eigenschaft des Parameters?
Wie genau kommen denn Parameter und Parameterdescription zusammen?

[chetigol]

Ist denn die Parameterdescription nicht eigentlich eine Eigenschaft des Parameters?
Wie genau kommen denn Parameter und Parameterdescription zusammen?

Ja, sorry! Habe es etwas schlecht ausgedrückt! Die ParameterDescription ist eine superklasse für alle weiteren ParameterDescriptions.
Würde dann eine weitere Klasse bauen, welche eine Liste dieser descriptions beinhaltet:


abstract class ParameterDescription{
....
...
}

class Parameter1Description extends ParameterDescription{
}

class Parameter2Description extends ParameterDescription{
}



und dann eine Klasse, welche diese kapselt:


class DescriptionList{
Hash<Integer, ParameterDescription> Liste;

add( ParameterDescription p ){
Liste.put( p.kennung, p );
}

get( int kennung ){
return Liste.get( p.kennung );
}
}



und dann könnt ich diese DescriptionList dem Generator übergeben:



DescriptionList pars = new DescriptionList;

pars.add( new Parameter1Description (1234, 1 ,1) );
pars.add( new Parameter2Description (133234, 3 ,1) );

core = new GeneratorGore( pars );

[Tiamat]

Sorry, aber ich blick da so net durch.
Ohne die exakte Aufgabenstellung zu kennen, kann ich net beurteilen,
ob das ne gute Idee ist oder nicht.

Im Moment weiß ich nur, dass irgendwelche Parameter(50 verschiedene Typen), unter welchem Begriff ich eigentlich was anderes verstehe, über Generatoren in Listen erzeugt werden und dann per OutputStream in ein File geschrieben werden sollen.

[chetigol]

Sorry, aber ich blick da so net durch.
Ohne die exakte Aufgabenstellung zu kennen, kann ich net beurteilen,
ob das ne gute Idee ist oder nicht.

Im Moment weiß ich nur, dass irgendwelche Parameter(50 verschiedene Typen), unter welchem Begriff ich eigentlich was anderes verstehe, über Generatoren in Listen erzeugt werden und dann per OutputStream in ein File geschrieben werden sollen.


hehe, ok dann versuch ichs nochmal!

Unter Parameter ist ein Binär, - Text oder XML - File gemeint mit einer fest definierten Datenstruktur! Diese Files werden dazu benutzt um ein System ( bestehend zu 90% aus einem Embeded-System, + einige Services auf einem Server ) zu Parametrieren! Also bestimmte Funktionalität vorzuschreiben, Pegelangaben, usw.

Es gibt bereits eine GUI, welche die Eingaben in eine Datenbank schreibt. Jetzt muss ein tool gebaut werden, welches diese Daten aus der Datenbank in einer vorgeschriebenen struktur in ein Binärfile schreibt.
Ein sehr einfaches beispiel für einen Parameter wäre:


struct {
byte OutputLevel[LINE_COUNT];
byte InputLevel[LINE_COUNT];
byte LineStatus[LINE_COUNT]; // 0..off; != 0 .. on
}



Wenn etwas geänder wurde, so wird von der an ein Generator-Tool eine Liste mit ParameterIds übergeben, welche neu zu erzeugen sind.
Es gibt unterschiedliche Systemparameter-Typen, welche bestimmte voraussetzungen erfüllen müssen.

Jeder Parametertyp hat erstmal eine eindeutige Kennung, deshalb mal eine allgemeine superklass:


class ParameterDescription{
int kennung;
}


Von dieser leiten sich dann die entsprechenden Parametertypen ab, zB die LowLevel SystemParameter:


class LowLevelParameterDesc extendsParameterDescription{
int common;
int size;
byte compressed;
}


die Eigenschaften sind "statisch"! sie definieren das Verhalten dieses Parameters im System und wie dieser Parameter vom System behandelt werden soll! Enweder werden sie aus einer Datenbank entnommen, oder Hardcoded erstellt.


ParamDescListe list = new ParamDescListe();

// Definition eines LowLevel Parameters mit der kennung: "1" / common: true / size: 10kB / compression: false
list.add( new LowLevelParameterDesc( 1, true, 10000, false ) );

// Definition eines LowLevel Parameters mit der kennung: "2" / common: false/ size: 4kB / compression: false
list.add( new LowLevelParameterDesc( 2, false, 4000, false ) );

....usw


Das war nur eine Definition bzw. Beschreibung der vorhandenen Systemparameter. Für jeden Parametertyp muss es auch einen Genrator geben.


// erstmal ein Generator-Interface
interface Generator{
generate( ParameterDescription par, Stream out );
}


// davon abgeleitet die eigentlichen generatoren:

// Generator für Parametertyp1
class GeneratorPar1Bin extends Generator {

generate( ParameterDescription par, Stream out ){

schreibeHeader( par );

// schreibt daten in den out-stream
// zB die Leveldaten
for ( i = 0; i < COUNT; i++ )
out.writeByte( HoleOutputLevelAusDB(i) );

for ( i = 0; i < COUNT; i++ )
out.writeByte( HoleInputLevelAusDB(i) );

// usw, bis der Record fertig ist
}
}


// ähnliches gild für Parametertyp2
class GeneratorPar2Bin extends Generator {

generate( ParameterDescription par, Stream out ){

schreibeHeader( par );

// schreibt daten in den out-stream
}
}


Das übergebene ParameterDescription - objekt an den dazugehörigen Generator ist wichtig, da aus diesen Daten zum Beispiel der Header generiert wird.
Oder nach dem Generieren kann/muss überprüft werden, ob die Parametergröße, welche in der jeweiligen Description definiert wurde (im folgenden Fall 10kB):


// Definition eines LowLevel Parameters mit der kennung: "1" / common: true / size: 10kB / compression: false
list.add( new LowLevelParameterDesc( 1, true, 10000, false ) );


...mit der tatsächlich generierten Größe übereinstimmt!


Nachdem die Generatoren implementiert wurden, müssen sie nur noch installiert werden:


// installiere Generator für Parameterkennung 1
generatorCore.installGenerator( new GeneratorPar1Bin(1) );


// installiere Generator für Parameterkennung 2
generatorCore.installGenerator( new GeneratorPar2Bin(2) );




Jetzt zum Ablauf:

1. der Core wird von einem anderen Modul aufgerufen mit der zu generierenden Paraemterliste:


....
// starte Generator und Generiere alle Parameter in der Liste "parameter2Generate"
generatorCore.startGenerate( parameter2Generate[] );
...


Im Core:



void startGenerate( int[] parameter2Generate ){
for( i = 0; i < parameter2Generate.size; i++ ){

// holt den dazugehörogen parameter
gen = getGenerator( parameter2Generate[i] )

if ( gen != null ){

// hier wird der installierte Generator aufgerufen!
// die parameterListe liefert das zuvor installierte ParameterDescription - Object
// zu diesem Parametertyp
gen.generate( parameterListe.getParameterDescription(parameter2Generate[i]), out );
}
}


}



So, ich hoff, das ist etwas verständlicher. :confused:

[Tiamat]

Hi,
ja auf jeden Fall ist das verständlicher :)
Also alle erwähnten Klassen werden von der Core Klasse benötigt.
Es wird eine Liste erzeugt, in dem diese 50 Parametertypen eingefügt werden. Anschließend werden die Generatoren diese Liste durchlaufen,
und schauen welcher Parametertyp zum jeweiligen Generator gehört.
Der jeweilige Generator verrichtet seine Arbeit und schreibt das Ergebnis per OutputStream in ein File.


Die Anforderung war glaube ich , Generator und Parameter unabhängig voneinander zu deklarieren.

Das hast du ja getan, jetzt musst du noch dafür sorgen, dass Parameter ,Generator und Liste problemlos miteinander arbeiten können.

Die Frage ist halt wo diese Berechnungen stattfinden sollen.
Wenn die Fremdklasse dann alle Daten von Core erwartet, dann muss diese Parametergeschichte wohl im Konstruktor von Core stattfinden, damit diese bei Objekterschaffung vorhanden sind.

Was ich anders machen würde, was aber geschmackssache ist : Bevor ich 50 Klassen von ParamDescription und 50 Klassen von Generator in der Form erzeugen würde, würd ich das ganze mit einem Array of Paramdescription und Array of Generator tun.
Das erspart zig Objekterzeugungen und bietet sich dafür an, den zugehörigen Generator zu ParamDescription mit dem gleichen index zu versehen.

Und wenn du schon Generatoren in der Core Klasse verwaltest, kannst du die ParamDescriptions auch gleich dort verwalten.
Es hängt halt wirklich davon ab, wo genau diese Berechnungen stattfinden sollen. Wenn in Core, dann würde ich es so machen, sofern
es nicht gegen die Anforderungen spricht, die du erhalten hast.

Gruß
Tiamat

[Ectoplasma]

Hmmm ...

Also mal zu den Objekten. Eine ParameterDescription sollte nur einen einzigen Parameter beschreiben und nicht viele Parameter. Sonst ist der Name der Klasse semantisch, jedenfalls für mich, unklar. Daher kommt bei mir das anfängliche Verständnisproblem. Und wie schon oben erwähnt, sollte es nur eine einzige ParameterDescription Klasse geben. Wozu auch mehrere? Dem Parameter selbst würde ich keine Kennung oder Id geben, sondern nur der Description. Dann würde ich auch keine Zahl als Id vergeben, sondern einen String! Soetwas wie einen Mime-Type, der an der Description hängt. Ich werde im Laufe des Tages mal ein wenig Quellkode dazu schreiben.

[chetigol]

Hmmm ...

Also mal zu den Objekten. Eine ParameterDescription sollte nur einen einzigen Parameter beschreiben und nicht viele Parameter. Sonst ist der Name der Klasse semantisch, jedenfalls für mich, unklar. Daher kommt bei mir das anfängliche Verständnisproblem. Und wie schon oben erwähnt, sollte es nur eine einzige ParameterDescription Klasse geben. Wozu auch mehrere? Dem Parameter selbst würde ich keine Kennung oder Id geben, sondern nur der Description. Dann würde ich auch keine Zahl als Id vergeben, sondern einen String! Soetwas wie einen Mime-Type, der an der Description hängt. Ich werde im Laufe des Tages mal ein wenig Quellkode dazu schreiben.

Der ParameterDescriptor beschreibt ja nur die Eigenschaften, die der Paraemter erfüllen muss. Man kann es auch in Konstanten ausdrücken:

// Beschreibung des ersten Parameters mit der ID 0
#define RECORD_0_ID 0;
#define RECORD_0_NAME "DeviceDescription";
#define RECORD_0_SIZE 20000;
#define RECORD_COMMON (byte)0xFF;

// Beschreibung des zweiten Parameters mit der ID 1
#define RECORD_0_ID 1;
#define RECORD_0_NAME "LineLevel";
#define RECORD_0_SIZE 1000;
#define RECORD_COMMON (byte)0x00;

usw.

Es gibt deshalb mehr als nur eine Parameter Description klasse, da Parametertypen zu generieren sind, welche mit den oberen Systemparametern nichts zutun haben. Also irgendwelche Service-Paramtrierungen;


#define RECORD_0_ID 66;
#define RECORD_0_NAME "ServiceXYParameter";


Die Descriptoren haben nichts mit den Daten zutun, sondern geben nur vor, wie diese aussehen sollen (size,...). Diese Vorgaben sind FIX vom System vorgegeben, da es sich dabei um fixe C - Strukturen handelt.

Ich wollte jetzt einfach einen ParameterDescriptor mit einem dazugehörigen Generator verknüpfen. sollte eigentlich kein Problem sein:

zB.:

new Generator(...., new ParameterDescriptor(.....) );


Mein Problem ist aber, Es gibt einen bestimmten System-Parameter, welcher Daten aller SystemDescriptoren enthält:


struct _parameterDescr {
byte parameterId;
char parameterName[NAME_LENGTH];
byte size;

}parameterDescription[PARAMETER_COUNT]



Der Generator dieses Parameters müsste dann alle descriptoren durchgehen und die Daten auslesen und ins file schreiben!
Wie mach ich das am besten?

1. Dieser Generator bekommt im Konstruktor die Liste aller Generatoren übergeben und liest die Descriptoren raus:

new GeneratorParameterDescr( GeneratorCore.getGenerators() );


--> gefällt mir irgendwie nicht

2. Die descriptoren werden zusätzlich in einer Liste gespeichert, und diese wird übergeben:


descriptorList.add( new ParameterDescriptor(.....) );
new Generator1(...., descriptorList[index] ); // index vom oberen descriptor

descriptorList.add( new ParameterDescriptor(.....) );
new Generator2(...., descriptorList[index] ); // index vom oberen descriptor

descriptorList.add( new ParameterDescriptor(.....) );
new Generator3(...., descriptorList[index] ); // index vom oberen descriptor

descriptorList.add( new ParameterDescriptor(.....) );
new GeneratorParameterDescr( descriptorList, descriptorList[index] );

In der untersten anweisung bekommt der Generator die Liste mit allen Descriptoren übergeben.

--> gefällt mir auch nicht! Da inkonsistenzen zwischen dem Descriptor, den ein Generator hat und einem in der Liste entstehen können!
Was ist, wenn jemand einen Descriptor aus der "descriptorList" versehentlich durch einen anderen mit gleicher ID aber unterschiedlichen Daten ersetzen sollte? Dann zeigt aber der Generator immernoch auf das ursprüngliche Objekt, obwohl in der Liste ein anderes eingetragen ist. Das hat wiederum zur Folge, dass die Daten, die vom "GeneratorParameterDescr" geschrieben werden (aus der descriptorList), mit denen der einzelnen Generatoren nicht zusammenpassen.

[chetigol]

Hi,

Und wenn du schon Generatoren in der Core Klasse verwaltest, kannst du die ParamDescriptions auch gleich dort verwalten.
Es hängt halt wirklich davon ab, wo genau diese Berechnungen stattfinden sollen. Wenn in Core, dann würde ich es so machen, sofern
es nicht gegen die Anforderungen spricht, die du erhalten hast.



Dass ich die Liste mit den PaameterDescriptions auch im Core verwalte gefällt mir nur bedingt! Eigentlich benötigen nur die einzelnen Generatoren die Daten aus den Descriptions.
Muss mir da noch etwas überlegen!