Java Frage (über aktuelles Objekt).

[Unfug]

So hab da nochmal eine Java Frage.
Ich hoffe ich kann sie so stellen, daß ihr es versteht:

Ich habe eine Klasse: ABC.class extends Vector

diese hat folgende Methode:

public ABC methode(ABC a) (Also will ein RETURN von einem ABC Objekt , sowie eine Übergabe von einem ABC Objekt, ABC ist ein Vector).
{
addElement(a.elementAT(0)); //das ElementAT(0) vom Vector a wird an dem Vector übergeben, welcher die MEthode aufgerufen hat.

return ??????? <<< wie gebe ich nun den Vector zurück, der die Methode aufgerufen hat?


}

[pdOrta]

Wenn ich dich richtig verstanden habe?
Willst du wissen wie du die Referenz des Objectes bekommst
dessen Methode du aufrufst.

Das ist dann "this"

Deine Methode sollte dann so aussehen

public ABC methode(ABC a){
addElement(a.elementAT(0));
return this; //übergibt seine Referenz zurück
}

Kann aber auch sein das ich dich völlig missverstanden habe! :(
Könntest du dann mehr Code posten.

pdOrta

[Unfug]

danke, klappt prima.

[Aqualon]

Man kann aber über die Sinnigkeit des ganzen diskutieren. Das Objekt, das die Methode von ABC aufruft, braucht sowieso schon eine Referenz auf ABC, sonst würde der Methodenaufruf ja nicht funktionieren. Warum willst du also dann die Referenz nochmal zurückgeben, wenn sie das aufrufende Objekt eh schon hat?

Aqua

[Unfug]

ich habs verrändert

[HellHorse]

Man kann aber über die Sinnigkeit des ganzen diskutieren. Das Objekt, das die Methode von ABC aufruft, braucht sowieso schon eine Referenz auf ABC, sonst würde der Methodenaufruf ja nicht funktionieren. Warum willst du also dann die Referenz nochmal zurückgeben, wenn sie das aufrufende Objekt eh schon hat?

Aqua
Damit lässt sich toller Code wie

aVector.add("1").add("2").add("3").add("4")....

schreiben. :ugly:

Die grössere Sinnlosigkeit sehe ich darin, Vector zu verwenden.

[pdOrta]

Die grössere Sinnlosigkeit sehe ich darin, Vector zu verwenden.

Warum?
Der Container sollte doch zum Problem passen.
Welches aber hier nicht bekannt ist.

Man kann aber über die Sinnigkeit des ganzen diskutieren. Das Objekt, das die Methode von ABC aufruft, braucht sowieso schon eine Referenz auf ABC, sonst würde der Methodenaufruf ja nicht funktionieren. Warum willst du also dann die Referenz nochmal zurückgeben, wenn sie das aufrufende Objekt eh schon hat?

Der Sinn liegt darin. Das man falls der Aufruf keinen Fehler verursachen oder Exception werfen kann die referenz gleich weiter benutzen kann ohne diese selbst gesichert zu haben.

Bsp:
gfxContainer.Add(new Widget().setColor(black)).Paint();

Widget w = new Widget();
w.setColor(black);
gfxContainer.Add(w);
gfxContainer.Paint();

Macht aber nur dann Sinn wenn es 100%ig sicher ist das bis zum Paint nichts fehlschlagen kann!

[HellHorse]

Warum?

weil Sun selbst ihn als "legacy class" bezeichnet
weil er vor dem Collection Framework erstellt wurde
weil er eine Quelle von duplicated code ist und duplicated code pöse ist
weil er komplett synchronisiert ist
weil er eine konkrete Klasse statt einem Interface ist (zählt nur bei Typen von Variablen)


Siehe dazu:
http://java.sun.com/docs/books/tutorial/collections/problems/index.html
http://java.sun.com/docs/books/tutorial/collections/implementations/general.html

[Aqualon]

Was meint Sun denn mit Legacy Operations? Und kannst du mir den Satz "[...] but Vector has loads of legacy operations, so be extra careful to always manipulate the Vector with the List interface, or you'll be stuck with it for life." erklären? Verstehe nicht so ganz, was das "you'll be stuck" bedeuten soll.

Aqua

[HellHorse]

Was meint Sun denn mit Legacy Operations? Und kannst du mir den Satz "[...] but Vector has loads of legacy operations, so be extra careful to always manipulate the Vector with the List interface, or you'll be stuck with it for life." erklären? Verstehe nicht so ganz, was das "you'll be stuck" bedeuten soll.

Aqua
Den "Unterschied" zwischen Vector und List. Z.b. die alte #addElement Methode von Vector die nicht in List definiert ist. Wenn du die statt #add von List verwendest, und dann den Vector gegen eine LinkedList austauschen willst, hast du ein Problem.
Darum "gegen List programmieren".

[pdOrta]

> weil Sun selbst ihn als "legacy class" bezeichnet
> weil er vor dem Collection Framework erstellt wurde
Das macht ihn deswegen noch nicht schlecht.

>weil er eine Quelle von duplicated code ist und duplicated code pöse ist
warum? Erzeugt der Vector den Code?

>weil er komplett synchronisiert ist
Würd ich nicht allgemein als Schwachstelle bewerten.

> weil er eine konkrete Klasse statt einem Interface ist
Nein!
List l = new Vector(); //geht.
List l = new List(); // geht net.
List l = new ArrayList(); // geht wieder.
Man kann keine Interfaces Instanzieren.
Siehe deine Links wenn Vector dann übers Interface.

>(zählt nur bei Typen von Variablen)
Da versteh ich nicht ganz was du meinst?

Der Container sollte zum Problem gewählt werden und nicht umgekehrt.
Darum halt ich von der Aussage der ... ist schlecht gar nichts.

>Darum gegen List programmieren.
Da sind wir uns einig.

pdOrta

[HellHorse]

> weil Sun selbst ihn als "legacy class" bezeichnet
> weil er vor dem Collection Framework erstellt wurde
Das macht ihn deswegen noch nicht schlecht.
Man sollte ihn einfach nicht mehr vewenden.

>weil er eine Quelle von duplicated code ist und duplicated code pöse ist
warum? Erzeugt der Vector den Code?
Denk mal über die Unterschiede zwischen den Klassen ArrayList und Vector nach.

>weil er komplett synchronisiert ist
Würd ich nicht allgemein als Schwachstelle bewerten.
Kann zu Deadlocks führen (ok, umwahrscheinlich aber möglich)
Ist langsamer (ok, vermutlich bloss minimal)

>(zählt nur bei Typen von Variablen)
Da versteh ich nicht ganz was du meinst?
gegen List programmieren

Der Container sollte zum Problem gewählt werden und nicht umgekehrt.

Dann sag mir doch mal bloss ein Problem, wo man Vector statt ArrayList oder LinkedList verwenden sollte (abgesehen von einer 1.1 oder 1.0 VM was sowieso fragwürdig ist oder wo die API es leider explizit verlangt wie gewisse XML-RCP Frameworks, dort ist es aber bloss zu Parameter übergeben und da braucht man sicher keine Subklassen).

[pdOrta]

>Dann sag mir doch mal bloss ein Problem,
Darunter schon mal ein paar ganz nette und plausible
Beispiele von dir. Und alles wo der Zugriff Sync sein muss.
zB: DBServer

>Subklassen....
War nicht die Frage.

>Denk mal über die Unterschiede zwischen den Klassen ArrayList und >Vector nach.
Erklärs mir.
ps: Es gibt mehr Java SDKs als die von SUN!
Die implementierung könnte da sehr unterschiedlich sein.
Aber ich habe was für dich ist aus SunJ5.

public class ArrayList<E> extends AbstractList<E>
implements List<E>, RandomAccess, Cloneable, java.io.Serializable

public class Vector<E>
extends AbstractList<E>
implements List<E>, RandomAccess, Cloneable, java.io.Serializable

Der Source ist ja im SDK dabei.

Irgendwie wiederholen wir uns!

pdOrta

[HellHorse]

>Dann sag mir doch mal bloss ein Problem,
Darunter schon mal ein paar ganz nette und plausible
Beispiele von dir.
Wo? Hab keines gesehen?

Und alles wo der Zugriff Sync sein muss.
zB: DBServer
Dafür braucht man aber nicht Vector sondern Collections.synchronizedList oder CopyOnWriteArrayList.

>Subklassen....
War nicht die Frage.
Oh doch, denn der Threadstarter subclasst und darauf bezog ich mich.


>Denk mal über die Unterschiede zwischen den Klassen ArrayList und >Vector nach.
Erklärs mir.
Vector und ArrayList. Zweimal die gleiche Funktionalität, zweimal die gleiche Implementation. Wie gross ist da wohl die Wahrscheinlichkeit duplicated Code zu finden?
(siehe weiter unten)

ps: Es gibt mehr Java SDKs als die von SUN!
Die implementierung könnte da sehr unterschiedlich sein.
Ja, irgend ein Spezi hat es bestimmt geschafft die gleiche Funktionalität auf zwei verschiedene Wege zu implementieren. :ugly:

Aber ich habe was für dich ist aus SunJ5.

Der Source ist ja im SDK dabei.
So ist es, und da finden wir:

public boolean add(E o) {
ensureCapacity(size + 1); // Increments modCount!!
elementData[size++] = o;
return true;
}


public synchronized boolean add(E o) {
modCount++;
ensureCapacityHelper(elementCount + 1);
elementData[elementCount++] = o;
return true;
}

(bitte nicht verkalgen Sun)

Irgendwie wiederholen wir uns!
Aye