Macht es Sinn Arraylisten mit Gettern zu übergeben?

[auxilium]

Also normalerweise soll ja alles bestenfalls private deklariert werden,


aber macht das sinn bei einer arraylist.

Wird die ganze arraylist übergeben, so kann ich immer noch werte ändern, da ja die arrayliste mit all ihren funktionen weitergegeben wird.

Gebe ich nur bestimmte funktionen der Arrayliste weiter, zb. die size(), dann läppert es sich an den funktionen.

 

[Niki]

Es kommt immer auf den Anwendungsfall an. Bei einem TableModel für eine JTable würde ich z.B. schon eine Methode setContent(List l) anbieten. Manchmal macht es aber auch nur sinn add und remove Methoden anzubieten.

 

[maki]

Ja, es ergibt Sinn.

Manchmal allein schon der Konvention wegen, einfacher.

 

[Marco13]

Dummerweise sind "einfach" und "gut" häufig nicht vereinbar. (Und wenn man sie DOCH vereinen kann, ist das "einfach gut" )

Man sollte IMHO auf keinen Fall sowas machen wie

class Bla
{
    private ArrayList<String> list = new ArrayList<String>();

    public ArrayList<String> getList() { return list; }
}

Das ist aus verschiedenen Gründen schlecht. Immernoch schlecht (aber etwas weniger schlecht) wäre

class Bla
{
    private List<String> list = new ArrayList<String>();

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

aber würde immernoch die Kapselung verletzen.


Sowas

class Bla
{
    private List<String> list = new ArrayList<String>();

    /** ... returns an unmodifiable view on the list... */
    public List<String> getList() { return Collections.unmodifiableList(list); }
}

kann OK sein, wenn man jemandem nur Lese-Zugriff auf die Liste geben will.

Sowas

class Bla
{
    private List<String> list = new ArrayList<String>();

    /** ... returns A COPY OF the List ... */
    public List<String> getList() { return new ArrayList<String>(list); }
}

wäre OK, aber der Kommentar ist dann besonders wichtig

Am saubersten (in bezug auf die Kapselung) ist aber tatsächlich sowas

class Bla
{
    private List<String> list = new ArrayList<String>();

    public int getListSize() { return list.size(); }
    public String getListElement(int index) { return list.get(index); }
}

 

[ARadauer]

Collections.unmodifiableList(list);

ohh nett das kenn ich noch nicht, man lernt nie aus

 

[maki]

Am saubersten (in bezug auf die Kapselung) ist aber tatsächlich sowas

Was wäre denn am deinem Beispiel davor (Kopie der Liste wird zurückgegeben -> immutable) an der Kapselung auszusetzen, schliesslich verhalten sich die meisten Standard Javatypen auch so?

 

[Marco13]

Daran ist nichts falsch (hab ich ja auch geschrieben (bzw. eben nicht :wink: )) aber es ist wichtig, dass das eindeutig und unmißverständlich dokumenteiert (oder am Methodennamen ersichtlich) ist (sonst fürgt jemand etwas zu dieser Liste hinzu, und wundert sich, wieso im Objekt nichts ankommt). Ob dieses Konstrukt noch Sinn macht, wenn man den "Listeninhalt verändern können" will, ist aber fraglich... Wenn man schon eine "addToList" Methode anbietet, würden "getFromList" und "getListSize" imho "konzeptionell" eher passen als ein "getCopyOfList"....

 

[Janus]

für rein lesenden zugriff lass ich solche klassen gern Iterable und Iterator implementieren, sofern kein random access nötig ist.

 

[Marco13]

Das ist zwar praktisch, aber beim Implementieren von Iterabel stellt sich immer die brennende Frage: WORÜBER Iteriert man? Bei Objekten, die z.B. zwei Listen kapseln, funktioniert das schon nichtmehr - da kann man bestenfalls zwei verschiedene "getIterator"-Methoden anbieten :?

 

[Wildcard]

Alles ist möglich, referenzen einer Liste, kopien einer Liste, besagte Unmodifiable Listen, Iteratoren, getter für einzelne Elemente, Arrays,...
Der Punkt ist, es muss zum Anwendungsfall passen und exakt in der Java Doc beschrieben sein

 

[Marco13]

Die Wichtigkeit der Dokumentation hatte ich (speziell bei den Formen, bei denen man nicht an der Signatur erkennt, was man bekommt) schon betont.

Aber eine Liste tatsächlich als echte Referenz zu übergeben, ist wohl nur SEHR, SEHR selten angebracht :? jeder "Idiot", der sich diese Liste holt, kann sie einfach löschen, oder (was meistens noch schlimmer wäre: ) sowas machen wie list.set(index, null); - und in der JavaDoc ALLES zu beschreiben, was man über die Liste annimmt ("...it is assumed that the caller will not set elements in this list to 'null'" usw.) wäre etwas, was man wohl kaum so konsequent durchhalten könnte...

Aber grundsätlich finde ich auch, dass man sich bei sowas am angedeuteten "Design by contract" orientieren sollte :toll:

 

[Wildcard]

Aber eine Liste tatsächlich als echte Referenz zu übergeben, ist wohl nur SEHR, SEHR selten angebracht :? jeder "Idiot", der sich diese Liste holt, kann sie einfach löschen, oder (was meistens noch schlimmer wäre: ) sowas machen wie list.set(index, null); - und in der JavaDoc ALLES zu beschreiben, was man über die Liste annimmt ("...it is assumed that the caller will not set elements in this list to 'null'" usw.) wäre etwas, was man wohl kaum so konsequent durchhalten könnte...

Hast du mal versucht eine Liste umzusortieren wenn du nur Kopien bekommst und lediglich eine setElementAt Methode oder sowas hast?
Wenn du dir zB EMF anschaust, dann ist es ganz normal dort einen getter für die original Referenz auf die Liste zu haben.
Das ist auch durchaus praktisch, weil man mit wenig Code viel erreichen kann. Zugegebener maßen sind die dort verwendeten ELists auch etwas cleverer als die java.util Listen. Sie haben zB Notification Support und erzwingen Constraints, wodurch die von dir beschriebenen Szenarien so nicht möglich sind, wenn nicht explizit erlaubt.
Davon abgesehen ist es auch (gerade bei Kopien) eine Performancefrage, Wenn es sich um eine sehr kritische Stelle handelt, kann das durchaus einen Unterschied machen.

 

[semi]

...und in JPA sollte man die Collections innerhalb von Entity-Beans nicht durch irgendwas anderes ersetzen
oder Kopien zurückgeben, da sie von der JPA Implementierung gemanaged werden (Stichwort: Proxy etc.)

 

[Marco13]

Naja, wenn man nur eine getElementAt und getSize hat kann man sowieso nichts an der Liste machen. Wenn man aber zusätzlich ein removeElement und insbesondere AUCH eine setElementAt bereitstellt, hat man sowieso schon so viel Zugriff gewährt, dass es OK wäre, dort auch eine echte Referenz zurückzugeben - man kann ja praktisch alles, was man mit der Referenz machen kann, auch mit den einzelnen Methoden machen :roll:
(Dann wäre das einzige Argument vielleicht noch die Kapselung des Typs, aber "List" ist so allgemein, dass das dann kaum noch eine Rolle spielt)

Ohne eine setElementAt methode wäre das Beispiel mit dem Sortieren natürlich ... hmgl :?

ArrayList elements = ...
while (x.getNumElements() > 0)
{
    Element element = x.getElement(0);
    elements.add(element);
    x.removeElement(element);
}
Collections.sort(elements);
for (Element element : elements) x.addElement(element);

... ja, sowas muß ja nicht sein

 

[ms]

...und in JPA sollte man die Collections innerhalb von Entity-Beans nicht durch irgendwas anderes ersetzen
oder Kopien zurückgeben, da sie von der JPA Implementierung gemanaged werden (Stichwort: Proxy etc.)

Das gilt aber nur für annotierte Methoden oder Felder. Man kann ja zusätzlich noch öffentliche Methoden bereitstellen, die wiederum eine sortierte Kopie oder dergleichen zurückliefern.

ms

 

[semi]

@ms
Klar, von mir aus auch rückwärts ausgeben Letztendlich schützt man sich dabei vor Problemen, die man kennt
und produziert überflüssigen Code. Wenn ich weiss, dass ich auf eine Collection nur lesend zugreife, warum soll
ich diese immer kopieren? Ich ändere ja nichts.
Wenn man es so sieht, müsste man überall, wo Referenzen im Spiel sind, Kopien erzeugen. Nicht nur bei Collections,
Arrays etc.
z.B. wenn ein Objekt einen Datensatz, sagen wir mal Adresse, zurückgibt, habe ich über die Setter Zugriff auf die
Interna der Adresse und kann sie manipulieren. Man müsste davon wieder eine Kopie anfertigen, um das Original
"zu schützen" oder zwei Versionen anbieten, Mutable und Immutable. Frage ist nur wen schützt man vor wem?

 

[ms]

Frage ist nur wen schützt man vor wem?

Genau darum kann man pauschal nicht sagen was besser ist und was nicht, weil es letztendlich von der Anwendung abhängt.

ms

 

[Wildcard]

Genau darum kann man pauschal nicht sagen was besser ist und was nicht, weil es letztendlich von der Anwendung abhängt.

Ganz genau. Und die gewählte Methode wird in Java Docs festgehalten die dann den 'Vertrag' für die Methode darstellt.

 

[semi]

OK, dann zitiere ich mich selbst und formuliere das hier

Wenn ich weiss, dass ich auf eine Collection nur lesend zugreife, warum soll
ich diese immer kopieren? Ich ändere ja nichts.

in das hier um.

Wenn ich weiss, dass ich eine Collection ändern will, die ich laut API nicht ändern darf/soll, mache ich eine Kopie
davon und arbeite mit dieser weiter.

List<Address> list = new ArrayList<Address>(person.getAddressList());
Collections.sort(list, new AddressComparator());

Ich nehme an, da sind wir uns einig. :wink:

 

[ms]

OK, dann zitiere ich mich selbst und formuliere das hier

Wenn ich weiss, dass ich auf eine Collection nur lesend zugreife, warum soll
ich diese immer kopieren? Ich ändere ja nichts.

in das hier um.

Wenn ich weiss, dass ich eine Collection ändern will, die ich laut API nicht ändern darf/soll, mache ich eine Kopie
davon und arbeite mit dieser weiter.

List<Address> list = new ArrayList<Address>(person.getAddressList());
Collections.sort(list, new AddressComparator());

Ich nehme an, da sind wir uns einig. :wink:

Java bietet genügend Mechanismen um solche Vereinbarungen technisch zu realisieren. Warum sollte ich also
darauf verzichten und in der Api-Doc in prosa reinschreiben, dass jeder, der die Collection verwendet sie auf keinen Fall verändern darf?
Dein Ansatz kann funktionieren (zB. in Ein-Mann-Projekten) aber er muss nicht. Ich würde mich auch nicht darauf verlassen, dass jeder der die Funktion verwendet auch die Api-Doc liest. Dann produziert womöglich dein Programm einen Fehler obwohl der Entwickler Schuld daran ist. Da ist es doch wesentlich sicherer alle technischen Hilfsmittel zu verwenden und nur das Verhalten zu beschreiben anstatt eine Vorschrift zu deklarieren.

ms