Kapselung Member korrekt nach aussen verfügbar machen

[Scarabol]

Hi Leute,

bin seit kurzer Zeit von C++ zu Java gewechselt.

Ich vermisse "const" sehr. Daher folgende Frage:

Wenn ich in einer Klasse eine Member-Objekt speicher und dieses setzen möchte z.B.:

class test
{
meineKlasse obj;

public void setzteObj(meineKlasse variable)
{
// Methode 1
obj = variable;
// Methode 2
obj = new meineKlasse(variable);
}

public meineKlasse getObj()
{
// Methode 1
return obj;
// Methode 2
return meineKlasse(obj);
}
}

Welche Methode ist die bessere?
Macht es Sinn immer den Kopierkonstruktor zu benutzen?
Besonders wichtig ist natürlich, dass der Inhalt von obj NUR über set verändert werden kann und nicht über das von getObj() zurückgegebene Objekt/Referenz.

MfG
Scarabol

 

[ARadauer]

Methode 1

Generel in Java Klassen groß schreiben und es gibt sowas wie Standards wie ein getter und setter auszusehen hat...

zb

public class Test {
    
    private MeineKlasse obj;

    public MeineKlasse getObj() {
        return obj;
    }

    public void setObj(MeineKlasse obj) {
        this.obj = obj;
    }     

}

Wobei wenn ichs mir recht überlege macht, deine Variante 2 eigentlich was anderes. Gehst du davon aus das meineKlasse einen Copy Konstruktur implementiert?
In Variante 1 hättest du dann in der Klasse das selbe objekt. Und in Variante 2 hättest du ein neues..

 

[Scarabol]

Hi,

vielen Dank für deine Antwort.

Wie wird bei deinem getter verhindert, dass das Objekt verändert wird?

MfG
Scarabol

 

[bygones]

Hi,

vielen Dank für deine Antwort.

Wie wird bei deinem getter verhindert, dass das Objekt verändert wird?

MfG
Scarabol

zum einen in dem man nur getter bzw setter anbietet wenn es WIRKLICH noetig ist.
Per default sollte man keine anbieten.

Ansonsten bist du fuer die Aenderungsverhinderung zustaendig. Z.b. wenn die Variable nur ueber den konstruktor gesetzt werden soll, mach sie final.

Natuerlich musst du auch transitive Aenderungen beruecksichtigen, also wenn du ein Objekt zurueckgibst, soll dieses natuerlich auch am besten immutable sein.

Bei zb Collection gibts in der Klasse Collections die methoden unodifable, die deine Collection wrappen und unveraenderlich machen

 

[Marco13]

Ja, der Fluch und Segen von "const" (mit seiner im Vergleich zu "final" ja auch "tiefen" Bedeutung). Ein Segen, weil es sehr praktisch sein kann, und es erlaubt, sauber gekapselten Code zu schreiben und Veränderbarkeit einzuschränken. Ein Fluch, weil ... na, das weiß jeder, der schonmal bei einer tief im Code versteckten

void doSomething(const * const something) const;

gek**** hat, weil der Compiler sich beschwert ... die "Const-Correctness" kann SO einen Haufen Doppel- und Dreifacharbeit (in bezug auf Planung UND Implementierung) bedeuten, dass ... mir das einfachere, klarere Java da doch lieber ist.

Aber es stimmt schon, dass das "Tiefe Const" von C++ in Java nur bedingt (und wenn, dann nur bedingt "schön") umgesetzt werden kann. Ein nicht unübliches Pattern hat bygones mit den Collections.unmodifiable* schon angedeutet: Wenn man z.B. eine List speichert, sollte man die i.a. nicht veränderbar nach draußen geben:

class SomeClass
{
    private List<String> list = ...

    public List<String> getList()
    {
        return Collections.unmodifiableList(list);
    }
}

Etwas allgemeiner und flexibler kann man gegebenenfalls (das muss man sich überlegen) bei eigenen Klassen/Interfaces sein. Zum Beispiel KÖNTNE es sowas geben wie

interface Person {
    String getName();
}

interface MutablePerson extends Person {
    void setName(String name);
}


class SomeClass
{
    private MutablePerson person = new DefaultPerson();

    public Person getPerson()
    {
        return person; // Gibt nur "Person" nach draußen - Person kann nicht geändert werden
    }
 
    private void doRename()
    {
        this.person.setName("New Name"); // Intern ist aber die Veränderbare Person bekannt!
    }
}

Das kann, wenn man es Konsequent umsetzen will, auch ein bißchen aufwändig werden, aber es bietet einige Interessante Möglichkeiten (z.B. in Verbindung mit Kovarianz)

 

[Scarabol]

ok danke euch.

Abschließend noch eine Frage:

[Java]
public void test(meineKlasse obj)
{
member = obj;
}

meineKlasse busted = new meineKlasse();
test(busted);
[/Java]

Was passiert mit member, wenn busted wirklich zerstört wird?

MfG
Scarabol

 

[Gast2]

Die Referenz die member auf das Objekt meineKlasse hat wird mitgelöscht. Das Objekt an sich bleibt aber weiterbestehen solang noch Referenzen darauf existieren.