XML-Parsing / public-Member-Variablen / Design-Frage

[Sergeant_Pepper]

Hallo,

ich habe eine kleine Web-Anwendung geschrieben, die XML-Daten auswertet.

Das Parsing mache ich mit SAX/xerces und verwende mehrere Event-Handler (auf Basis von XMLFilterImpl), die ich per Pipeline "verkette". Funktioniert so wie es soll.

Das Verhalten der verschiedenen Handler möchte ich nun genauer steuern (u.a. Suchstrings festlegen).

Ich will die Steuerungs-Parameter in einer eigenen Klasse bündeln. Diese Klasse "Params" wird mehrere Booleans und einige Strings enthalten, jedoch keine Methoden. Nun denke ich mir, diese Felder "public" zu definieren und keine getter- und setter-Methoden zu schreiben. Es gibt beim Setzen der Werte nichts zu prüfen. Ich meine, das direkte Auslesen der Werte aus dem Objekt ist hier effizienter.

Wie seht Ihr das?

 

[Tobias]

Bist du sicher, das nicht doch irgendwann eine Prüfung dazukommt? Gibt es notwendige Bedingungen, zum Beispiel "Das Objekt muss immutable sein"? Soll das Objekt irgendwann mal an anderen, möglicherweise nicht vertrauenswürdigen Code rausgegeben werden?

Ohne diese Informationen ist das alles schwer zu beurteilen. Solange aber keine Prüfungen erforderlich (und auch niemals sein werden, weil alle Properties unabhängig voneinander sind), Strukturbedingungen wie "immutable" nicht vorhanden sind und der umgebende Code vertrauenswürdig ist, bzw das keine Rolle spielt, weil man mit dem Steuerobjekt eh nix kaputt machen kann, spricht nichts gegen öffentliche Properties.

 

[maki]

>> . Ich meine, das direkte Auslesen der Werte aus dem Objekt ist hier effizienter.

Wir wissen doch wozu voreilige Performance Optimierungen führen... unter anderem zu schlechtem Design und nur sehr selten zu Performanceverbesserungen, denke an die 80/20 Regel.

 

[Guest]

@Tobias und Maki: vielen Dank für Eure Meinungen

Gibt es notwendige Bedingungen, zum Beispiel "Das Objekt muss immutable sein"? Soll das Objekt irgendwann mal an anderen, möglicherweise nicht vertrauenswürdigen Code rausgegeben werden?

Immutable heißt, dass das Objekt nie verändert werden darf? Habe dazu gerade im "Krüger" etwas über das Immutable-Pattern gelesen. Wenn alle Pattern so simpel wären...
Der Haken: ich mag keine Methoden oder Konstruktoren mit vielen Parametern. Daher ja auch die Bündelung meiner Parser-Parameter in einer Klasse.

Ohne diese Informationen ist das alles schwer zu beurteilen. Solange aber keine Prüfungen erforderlich (und auch niemals sein werden, weil alle Properties unabhängig voneinander sind), Strukturbedingungen wie "immutable" nicht vorhanden sind und der umgebende Code vertrauenswürdig ist, bzw das keine Rolle spielt, weil man mit dem Steuerobjekt eh nix kaputt machen kann, spricht nichts gegen öffentliche Properties.

Kaputt machen kann man mit dem Objekt eigentlich nichts. Bislang ...

 

[Sergeant_Pepper]

"Gast" = meine Wenigkeit...

OT: wieso kann man hier eigentlich als Gast Beiträge verfassen?

 

[Tobias]

Das mit dem "simpel" beim Immutable-Pattern: Die Idee ja, die Umsetzung nicht immer.

Wegen Methoden und Konstruktoren mit vielen Parametern: Grundsätzlich richtig, aber man kann auch "Einmal"-Setter benutzen:

public void setMyString(String myString) {
    if(this.myString != null) {
        throw new IllegalStateException("Daref nur einmal gesetzt werden!");
    }
    this.myString = myString;
}

 

[Leroy42]

OT: wieso kann man hier eigentlich als Gast Beiträge verfassen?

Da gab's hier schon einige Diskussionen.

Ich persönlich sehe das als Anreiz hier (erst einmal) überhaupt zu posten.

 

[maki]

>> Der Haken: ich mag keine Methoden oder Konstruktoren mit vielen Parametern. Daher ja auch die Bündelung meiner Parser-Parameter in einer Klasse.

Kannst dir ja mal das Builder Pattern ansehen

 

[Sergeant_Pepper]

Danke maki, das mache ich mal