Ich gebe eine ArrayList als List zurück per MEthode, wie kann ich nun aber die ArrayList speichern?

[berserkerdq2]

Hi, ich habe eine Methode, dessen Rückgabewert List ist, ich verwende in der Methode jedoch eine ArrayList und die gebe ich zurück und das klappt auch mit Rückgabewert List. Mein Problem ist nur, dass ich nun extern den Rückgabewert nur in List und nicht in ArrayList speichern kann, ist das schlimm? Soll ich einfach List verwenden, also macht das einen Unterschied oder kann man irgendwie die List in Arraylist speichern?

 

[KonradN]

Hi, ich habe eine Methode, dessen Rückgabewert List ist, ich verwende in der Methode jedoch eine ArrayList und die gebe ich zurück und das klappt auch mit Rückgabewert List. Mein Problem ist nur, dass ich nun extern den Rückgabewert nur in List und nicht in ArrayList speichern kann, ist das schlimm? Soll ich einfach List verwenden, also macht das einen Unterschied oder kann man irgendwie die List in Arraylist speichern?

Das ist das richtige Vorgehen. Du solltest überall, wo es möglich ist, direkt mit den Interfaces arbeiten und nicht mit konkreten Klassen! Daher sollte eigentlich an (fast) allen stellen nur mit List gearbeitet werden.

Das ist ein wichtiges Prinzip von Clean Code. Du musst Dir nur vorstellen, was es bedeutet, wenn Du statt einer ArrayList plötzlich eine andere List nutzen willst. Du kannst dann alles ändern. Oder was, wenn Du nun zwei Codeteile hast und die arbeiten mit unterschiedlichen Implementationen von List? Dann müsstest Du hin und her Konvertieren?

Also daher: So wie Du es gemacht hast überall Interfaces verwenden. Nur da, wo es nicht vermeidbar ist (z.B. bei der Erstellung) die Klasse nutzen.

 

[Gelöschtes Mitglied 65838]

wenn du unbedingt die arraylist eigenschaften in der anderen klasse brrauchst, dann gib statt der Liste einfach die arraylist zurück

 

[berserkerdq2]

Das ist das richtige Vorgehen. Du solltest überall, wo es möglich ist, direkt mit den Interfaces arbeiten und nicht mit konkreten Klassen! Daher sollte eigentlich an (fast) allen stellen nur mit List gearbeitet werden.

Das ist ein wichtiges Prinzip von Clean Code. Du musst Dir nur vorstellen, was es bedeutet, wenn Du statt einer ArrayList plötzlich eine andere List nutzen willst. Du kannst dann alles ändern. Oder was, wenn Du nun zwei Codeteile hast und die arbeiten mit unterschiedlichen Implementationen von List? Dann müsstest Du hin und her Konvertieren?

Also daher: So wie Du es gemacht hast überall Interfaces verwenden. Nur da, wo es nicht vermeidbar ist (z.B. bei der Erstellung) die Klasse nutzen.

Okay dnake, aber kann ich List nutzen? Also Elemente auslesen etc?

 

[KonradN]

Okay dnake, aber kann ich List nutzen? Also Elemente auslesen etc?

Das ist ja alles in dem Interface List enthalten. Es sollte normalerweise keinen Grund geben, auf irgendwelche Dinge zuzugreifen, die nur die ArrayList hast.

 

[LimDul]

Ich wiederhole mich gerne. Es ist sinnvoll die API-Doc zu lesen: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/List.html

Alternativ - probier es doch einfach aus.

Das Interface bietet dir alle Methoden an, in 99,999% der Fälle reicht das.

 

[berserkerdq2]

Ich wiederhole mich gerne. Es ist sinnvoll die API-Doc zu lesen: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/List.html

Alternativ - probier es doch einfach aus.

Das Interface bietet dir alle Methoden an, in 99,999% der Fälle reicht das.

Okay, da war ich mir nicht sicher, dachte vielleicht kann es zu Problemen führen, danke

 

[Gelöschtes Mitglied 65838]

probleme hast du erst wenn du eine methode brauchst die zb nur die arraylist kann und im list interface nicht festgelegt wurden... ab da musst du entweder casten oder gleich die arraylist zurück geben

 

[Gelöschtes Mitglied 65838]

das casten wäre die schlechtest möglcihe lösung nur so nebenbei erwähnt

 

[KonradN]

das casten wäre die schlechtest möglcihe lösung nur so nebenbei erwähnt

Daher hätte ich dies auch nicht erwähnt. Man kann hhie rja - da ein konkreter Fall gegeben ist - genau schauen, was denn ArrayList mehr bietet als List. Und das ist nicht viel. ensuceCapacity gäbe es da z.B. aber das geht halt direkt auf interne Implementationsdetails die eben eigentlich uninteressant sein sollten.

Es geht statt dessen immer den Weg der Interfaces: man überlegt sich, was man überhaupt machen will. Was braucht man?

Braucht man wirklich eine Liste? Oder reicht schon eine Collection? Oder ggf. sogar ein Iterable? Und das entsprechende setze ich dann voraus.

Ein java.util.ArrayList voraus zu setzen bringt einem schnell Probleme - so es nicht rein intern ist. So gibt es auch noch mindestens eine weitere ArrayList, welche eine interne Klasse einer anderen Klasse ist (ich weiss jetzt nicht mehr genau, wo das war. Arrays?). Aber es kann ja noch weitere Implementationen geben. Es ist einfach Quatsch, sich da festzulegen, denn es führt früher oder später zu Folgeproblemen.

 

[Gelöschtes Mitglied 65838]

wenn jemand gerade lernt wie das mit Interfaces und klassen funktioniert sollte man vllt nicht gleich allles an den kopf werfen

zb. ich bezweifle ( kann mich auch irren ) dass der TE überhaupt weis wie man COllection oder Iterable hernimmt oder überhaupt weis was es alles an datenstrukturen gibt...

 

[KonradN]

wenn jemand gerade lernt wie das mit Interfaces und klassen funktioniert sollte man vllt nicht gleich allles an den kopf werfen

zb. ich bezweifle ( kann mich auch irren ) dass der TE überhaupt weis wie man COllection oder Iterable hernimmt oder überhaupt weis was es alles an datenstrukturen gibt...

Daher gab es von mir auch nur eine einfach gehaltene Antwort an den TE - die Verkomplizierung ging von Anderen aus.

ich weiss jetzt nicht mehr genau, wo das war. Arrays?

Und ja - java.util.Array$ArrayList war es - ein Blick in den Source zeigt dies direkt auf:
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/be44bff34df4/src/share/classes/java/util/Arrays.java - Zeile 3806.

 

[Gelöschtes Mitglied 65838]

und wo hab ich verkomplexisiiert ? dass man das original objekt zurück gibt anstatt das interface ? dass man casten KÖNNTE aber es eine schlechte lösung wäre ?wo ist es komplex

 

[KonradN]

Ich habe de meine eigene Sicht, die hier aber nichts zur Sache beitragen würde und daher werde ich diese nicht weiter ausführen.

 

[Neumi5694]

Ich hab's mir zur Angewohnheit gemacht, Eingangsparameter möglichst breitgefächert zu akzeptieren, also Interfaces, Iterable usw. wie oben auch schon erwähnt.
Den Rückgabewert geb ich hingegen so genau wie möglich an. Falls einem für die Weiterverarbeitung das Interface reicht, kann man ja für die Aufnahme des Rückgabewerts eine entsprechende Variable deklarieren.

Das hat vor allem den Sinn, dass in einer "List" so ziemlich alles drin sein kann, von EmptyList, UnmodifiableList bis zum Ergebnis von Arrays.asList oder subList. Wird hingegen eine ArrayList geliefert, so weiß man, dass man darauf nicht Rücksicht nehmen muss und mit der Liste direkt weiterarbeiten kann.
Interessant wird's noch, wenn man verschiedene Arten von SortedSets oder Maps verwendet, sowie EnumSet und EnumMap.

Hier scheiden sich wohl die Geister.

 

[Gelöschtes Mitglied 65838]

Hier scheiden sich wohl die Geister.

das ist wohl nicht das prolbem ,sondern dass es nicht besprochen wird

 

[KonradN]

Den Rückgabewert geb ich hingegen so genau wie möglich an. Falls einem für die Weiterverarbeitung das Interface reicht, kann man ja für die Aufnahme des Rückgabewerts eine entsprechende Variable deklarieren.

Ja und nein. Damit brichst Du in vielen Fällen schlicht die Kapselung und gibst ein Implementationsdetail preis.
Du kannst ja nur rein praktisch überlegen, was das bedeutet: Dein Interface ändert sich, wenn Du intern etwas umstellst.

Aber die Kernaussage ist richtig: Wenn Du eine Liste zurück gibst, dann gibst Du eine Liste zurück -> List. Da musst Du also nicht überlegen, ob evtl. eine Collection oder Iterable ausreichen würde (Du kennst die Verwendung ja nicht!). Bei einem Parameter kennst Du die Verwendung aber. Und da macht es dann Sinn, sich genau zu überlegen, was man dann braucht. Und wenn Du nur ein Iterable brauchst, dann nimmst Du keine List als Parameter.

Mit eigenen Klassen läuft es aber meist genau auf dies hinaus. Denn Du hast zu Deiner Klasse Dog oft schlich kein DogInterface sondern nur lauter Interfaces wie BarkAble, BiteAble, FeedAble, ... Aber sobald Du so ein Interface hättest, dann würdest Du es verwenden. Wäre sinnvoll, wenn es mehrere Implementation geben können sollte. Da kommt also schlicht YAGNI ins Spiel.

das ist wohl nicht das prolbem ,sondern dass es nicht besprochen wird

Fachliche Dinge werden doch besprochen. Irgendwie fühle ich mich gerade leicht verarscht. Nur weil ich meine Sichtweise auf diesen Thread bzgl. "wer aus meiner Sicht was wie verkompliziert hat" nicht diskutiere (weil schlicht ohne fachlichen Bezug) habe ich doch erst relativ viel Zeit aufgewendet, DIR gewisse Dinge zu erläutern (Natürlich nur aus meiner Sicht. Jeder darf seine eigene Sicht haben. Aber ich hoffe, ich konnte immer alles etwas begründen). Und dann kommt so eine Aussage?

 

[Neumi5694]

Ja und nein. Damit brichst Du in vielen Fällen schlicht die Kapselung und gibst ein Implementationsdetail preis.
Du kannst ja nur rein praktisch überlegen, was das bedeutet: Dein Interface ändert sich, wenn Du intern etwas umstellst.

Aber die Kernaussage ist richtig: Wenn Du eine Liste zurück gibst, dann gibst Du eine Liste zurück -> List. Da musst Du also nicht überlegen, ob evtl. eine Collection oder Iterable ausreichen würde (Du kennst die Verwendung ja nicht!). Bei einem Parameter kennst Du die Verwendung aber. Und da macht es dann Sinn, sich genau zu überlegen, was man dann braucht. Und wenn Du nur ein Iterable brauchst, dann nimmst Du keine List als Parameter.

Mit eigenen Klassen läuft es aber meist genau auf dies hinaus. Denn Du hast zu Deiner Klasse Dog oft schlich kein DogInterface sondern nur lauter Interfaces wie BarkAble, BiteAble, FeedAble, ... Aber sobald Du so ein Interface hättest, dann würdest Du es verwenden. Wäre sinnvoll, wenn es mehrere Implementation geben können sollte. Da kommt also schlicht YAGNI ins Spiel.

Nein, ich gebe preis, welches Format das Ergebnis hat, nichts weiter.
Ich kann innen ja auch new ArrayList<>(irgendwas) als Ergebnis liefern, der Aufrufende hat keine Ahnung, was innen abläuft. Nur kann er sich bei einer ArrayList sicher sein, dass er sie danach direkt verändern kann, was er bei einer List nicht sein kann.

Es ergibt sogar Sinn, sich zu überlegen, was man mit den Parametern anstellt. Und genau deshalb halt ich die Parameter so allgemein wie möglich und die Rückgabe so spezifisch wie möglich. Eine allgemeine Methode kann auch spezifische Parameter aufnehmen, aber nicht umgekehrt. An der Stelle fängt dann das Gecaste und/oder Umwandeln an, das ich tunlichst vermeiden möchte.

 

[LimDul]

Dem möchte ich widersprechen. Auch die Rückgabe sollte so generisch wie möglich sein, ansonsten leakt man Implementierungsdetails (und gar inner-Classes) nach außen. Wenn für den Aufrufer solche Details wichtig sind, ist das keine saubere API. Ein Aufrufer sollte eigentlich nur dafür Interessieren, welches "Verhalten" eine Rückgabe nach außen exportiert und nicht wie das Verhalten implementiert ist. Das heißt im Best-Case - wenn vorhanden - ein Interface.

Ich gestehe aber zu, dass es bei List problematisch sein kann, weil man darüber nicht so einfach Dinge spezifieren kann wie Modifiable / Unmodifiable, weil leider die Collection-Interfaces schlecht designed sind.

Aber wenn man sich - egal welche - größere Bibliothek anschaut, wird trotzdem immer List und so gut wie nie eine konkrete Implementierung nach außen gegeben.

 

[KonradN]

Ich kann innen ja auch new ArrayList<>(irgendwas) als Ergebnis liefern, der Aufrufende hat keine Ahnung, was innen abläuft. Nur kann er sich bei einer ArrayList sicher sein, dass er sie danach direkt verändern kann, was er bei einer List nicht sein kann.

Und selbst dann bist Du einmal festgelegt auf genau diesen konkreten Typ und damit ist Deine Implementierung, was die Flexibilität der Implementation angeht, limitiert.

Und wenn Du einmal in Dich gehst: Oft genug hast Du da dann etwas wie

ArrayList<..> getChildren() {
    return children;
}

Und dann hast du hier ein konkretes Implementierungsdetail.

Es ist nun einmal ein einfacher Punkt der Abstraktion - was bei objektorienter Entwicklung nun einmal eine wichtige Grundlage ist.

 

[Neumi5694]

Und dann hast du hier ein konkretes Implementierungsdetail.

Nur wenn du den Quelltext kennst (und dann kennst du die Implementierung ja eh). Könnte ja auch das hier sein:

ArrayList<..> getChildren() {
    return new ArrayList<>(children);
}

children kann dabei jede Art von Collection sein.


Aber bleiben wir mal bei der "Flexibilität der Implementierung".
Welchen Vorteil hätte man denn hierdurch?

Collection<..> getChildren() {
    return children;
}

 

[KonradN]

Welchen Vorteil hätte man denn hierdurch?

Du kannst es beliebig ändern. Es spielt keine Rolle, was Du da zurück gibst - so lange es eine Collection ist!

Erstes Beispiel von Dir:

children kann dabei jede Art von Collection sein.

Ja, aber du musst es durch einen Konstruktor jagen. Und zwar genau diesen Konstruktor (oder einen Code, der eben eine ArrayList zurück gibt).
==> Dieses Detail ist und bleibt somit vorgegeben!
==> Dadurch ist das, was zugrunde liegt, nicht mehr änderbar. Also dieses typische "getChildren().add(...)" (was ich für eine Unart halte, aber das ist erst einmal egal).

Wenn es nur Collection oder List ist, dann kann da auch ein List.of(...) sein, was eine List$ListN oder List$List12 zurück gibt. Oder eine Methode, die keine ArrayList sondern z.B. eine Arrays$ArrayList zurück gibt oder oder oder ...

Du limitierst Dich, was die Rückgabe angeht. Und das ist eines der generellen Kernthemen bei der Objektorientierung und den SOLID Principles und und und ... das findet sich eigentlich an vielen Stellen. Auch im Patterns Buch, auf das hier immer wieder verwiesen wird im Forum, wird dies angesprochen ("Head First Design Patterns" bzw. "Entwurfsmuster von Kopf bis Fuß").

Klar kannst Du es so machen. Aber es macht einfach keinen Sinn. Selbst innerhalb der Klasse wirst du ja vermutlich/hoffentlich auch eher etwas haben wie:
private List<Node> children;
und damit selbst da auf eine konkrete Klasse verzichten.

Also ich will Dir da nichts vorgeben! Du kannst da so verfahren, wie Du es für richtig hältst. Alles, was ich machen kann und will ist meine Sicht vorstellen und Gründe nennen, wieso ich so verfahre.

Vielleicht hilft auch eine andere Sichtweise: Ich will bei einer Methode bestimmte Informationen zurück geben. Das kann dann sein, dass ich eine Liste von Elementen zurück geben will. Das ist dann also eine Menge von Elementen eines bestimmten Typs in einer bestimmten Reihenfolge.
Was für wichtige Informationen liefert die ArrayList gegenüber der List, die an der Stelle relevant sind?
Klar: Wenn es relevante Informationen gibt, die ich bei der Rückgabe einer List verlieren würde, dann wäre hier tatsächlich eine ArrayList richtig und eine List falsch. Diese Frage musst Du aber beantworten können bei der Auswahl des Rückgabetyps.

 

[Neumi5694]

Ich denke, ein Kernthema ist, dass man beim Aufruf einer Methode nicht limitiert ist und weniger darin, was jene Methode nach außen weitergibt. Als Aufrufender möchte ich schon wissen, was ich kriege. Blackboxes kommen ja nicht in "einem" Format, sondern in einem spezifischen. Wie die Daten generiert werden, interessiert mich nicht, aber das Format muss passen.

Als Entwickler der aufgerufenen Klasse weiß ich, was bei der Berechnung rauskommt, der Rückgabewert wird ja in der Methode erstellt. Der Header kann entsprechend definiert werden oder ein Interface liefern, das ändert an der Berechnung nichts. Ich kann innen drin, auch 3 Kilometer Spaghetticode stehen haben, den Aufrufenden interessiert das nicht.
Wäre die Freiheit der Implementierung anhand von Rückgabetypen eingeschränkt, so würden wir Number anstatt Integer,Float oder Double als Rückgabewerte liefern und den Aufrufenden damit klarkommen lassen.

Wichtig ist meiner Meinung nach in der objektorientierten Programmierung, dass ich als Aufrufender von außen nicht limitiert werde.

Auf deine Frage im letzten Absatz. Für den Programmier der aufgerufenen Methode ändert sich nichts.
Für den Aufrufer ändert sich sehr wohl was. Wenn er weiß, welche Collection ankommt, dann kann er anders darauf reagieren. Wie ich mittlerweile schon des öfteren erwähnt habe, könnte er bei einer List nicht wissen, ob er Elemente ersetzen/hinzufgen/löschen kann. Wenn er aber den Typ kennt, weiß er das.

Wie gesagt, da scheiden sich die Geister

 

[KonradN]

dass ich als Aufrufender von außen nicht limitiert werde.

Und genau das findet halt statt. Da Du etwas überspezifiziert hast, bist du nun limitiert.

Als Versandhändler wirst Du auch nicht vorgeben, wie ein Produkt genau versendet wird. Das Produkt muss geliefert werden, ordentlich verpackt. Aber die genaue Größe des Pakets wirst Du nicht spezifizieren und damit bist Du beim Versand frei in der Verpackung.

Aber egal - Du darfst das gerne so weiter sehen.

 

[Neumi5694]

Und genau das findet halt statt. Da Du etwas überspezifiziert hast, bist du nun limitiert.

Inwiefern?

Ich bin nicht Versandhändler, sondern Kunde. Wenn der Versender sagt, ich liefer dir ein 60x60x30 Paket, dann weiß ich als Empfänger, dass ich ein Paket krieg und ich weiß, dass es 60x60x30 groß ist, kann mich gegebenenfalls darauf vorbereiten. Wenn der Versender mir allerdings nur ein Paket schickt, könnte ich beim Empfang Probleme kriegen, wenn ich keinen Platz zum Hinstellen hab. Dann muss ich es erst mal abmessen und einen geeigneten Platz dafür finden. Bin ich dadurch weniger limitiert?

Angenommen, es kommt ein Point2D.Double als Ergebnis (und das ändert sich auch nicht, die API ist definiert). Inwiefern limitiert mich das?Ich kann ihn als Point2D verwenden oder als Point2D.Double
Wenn ein Point2D als Ergebnis kommt, hab ich hingegen nur eine Möglichkeit, bzw. muss dann erst mal prüfen, welche Klasse er hat, wenn ich was bestimmtes will. Ehrlich gesagt seh ich mich bei der Variante doch mehr limitiert als bei der ersten.

Wo genau ist meine Limitierung, wenn ich mehr Informationen habe? Wenn ich die nicht brauche, ignorier ich sie einfach.

Das kannst du natürlich ebenfalls gerne so sehen, wie du magst.

ps: Auch als Versandhändler muss ich wissen, wie groß die Artikel sind, sonst passiert's, dass eine Sammelmünze in einem Ikea-Umzugskarton verschickt wird, man weiß ja vorher nicht, was verschickt werden sollte und hat einfach mal "einen" Karton für die Aufnahme vorbereitet, vorsichtshalber den größten, den ich finden konnte.

 

[KonradN]

Sorry, wenn due die Methode schreibst / die Rückgabe festlegst, dann bist Du nicht "Kunde" sondern natürlich "Versandhändler".
Aus meiner Sicht verdrehst Du das komplett.

Ansonsten einfach: Entwurfsmuster von Kopf bis Fuß, erstes Kapitel, OO-Prinzip: "Programmieren sie auf eine Schnittstelle nicht auf eine Implementierung".
Unabhängig ob Du "Versandhändler" oder "Kunde" bist: Das sollten beide wollen.

 

[Gelöschtes Mitglied 65838]

dann wäre man wieder an dem Punkt wo jede Klasse ein interface hat

 

[KonradN]

dann wäre man wieder an dem Punkt wo jede Klasse ein interface hat

Das war aber ein anderes Thema - YAGNI wäre da das Stichwort.

Hier geht es darum: Wir haben ein Interface und das will jemand nicht nutzen....

Aber egal - ich bin raus. Macht einfach

 

[Neumi5694]

Sorry, wenn due die Methode schreibst / die Rückgabe festlegst, dann bist Du nicht "Kunde" sondern natürlich "Versandhändler".
Aus meiner Sicht verdrehst Du das komplett.

Ansonsten einfach: Entwurfsmuster von Kopf bis Fuß, erstes Kapitel, OO-Prinzip: "Programmieren sie auf eine Schnittstelle nicht auf eine Implementierung".
Unabhängig ob Du "Versandhändler" oder "Kunde" bist: Das sollten beide wollen.

Um genau zu sein bist du der, der verdreht. Oder interpretierst du den von dir zitierten Text "dass ich als Aufrufender von außen nicht limitiert werde." tatsächlich so, dass damit der Programmier der aufgerufenen Methode gemeint ist? Das glaube ich nicht, sorry. Tschö, wir machen schon

 

[KonradN]

Um genau zu sein bist du der, der verdreht. Oder interpretierst du den von dir zitierten Text "dass ich als Aufrufender von außen nicht limitiert werde." tatsächlich so, dass damit der Programmier der aufgerufenen Methode gemeint ist? Das glaube ich nicht, sorry. Tschö, wir machen schon

Noch einmal zum Fokus:

Es geht darum, dass eine Methode geschrieben werden soll. Also ein Entwickler / Programmierer sitzt da um soll diese Methode schreiben. Und da ist die Frage:
a) Was ist die genaue Anforderung?
b) Wie kann der Entwickler den Code so schreiben, dass die Methode, die er jetzt gerade schreibt, möglich gut geschrieben ist.

Und da muss dann dieser Entwickler entscheiden, was er z.B. als Rückgabetyp festlegt.

 

[Neumi5694]

Noch einmal zum Fokus:

Da hättst du mal lieber einen anderen Text zitieren sollen, wenn du auf das Zitierte gar nicht eingehen willst. Man möchte fast meinen, dass du die kritisierten Texte gar nicht liest.

Nochmal:
"Ich denke, ein Kernthema ist, dass man beim Aufruf einer Methode nicht limitiert ist und weniger darin, was jene Methode nach außen weitergibt."
"[...]dass ich als Aufrufender von außen nicht limitiert werde."
Das ist es, was du zitiert hast und der Text davor steht im selben Post. Wenn es dir um was anderes geht, dann sag das auch. Aber du hast das hier kritisiert.

a)b) Als Entwickler schreibe ich so, dass die Methode möglichst gut nutzbar ist. Und der Nutzer hat - falls ein Interface als Rückgabewert geliefert wird - nicht den geringsten Vorteil.
Deshalb schreib ich eine Methode so:

Point2D.Double addVectors(Point2D v1, Point2D... otherVectors) {...}

Nimm alles an, liefere Details zu dem was rauskommt, um die bestmögliche Nutzungsmöglichkeit zu gewährleisten.

 

[KonradN]

Als Entwickler schreibe ich so, dass die Methode möglichst gut nutzbar ist.

Nein, das ist falsch. Du erfüllst Anforderungen und nicht mehr!

YAGNI ansehen! Das wäre hier jetzt ein Schlüsselwort!

Aber ich bin raus und werde weder Dich noch Jorek weiter igendwie überzeugen wollen. Argumente sind genannt, Quellen zum nachlesen auch. Macht daraus, was ihr wollt.

 

[Neumi5694]

Nein, das ist falsch. Du erfüllst Anforderungen und nicht mehr!

YAGNI ansehen! Das wäre hier jetzt ein Schlüsselwort!

Aber ich bin raus und werde weder Dich noch Jorek weiter igendwie überzeugen wollen. Argumente sind genannt, Quellen zum nachlesen auch. Macht daraus, was ihr wollt.

Die Grundanforderung eines jeden, der eine externe Library verwendet, ist, dass die angebotenen Methoden gut nutzbar sind.
Ok, machen wir. Tschüs

 

[thecain]

@KonradN Ich bin hier auch nicht ganz bei dir. Für die Stabilität zu gewährleisten, macht es mMn auf jeden Fall Sinn eher ein Interface zurückzugeben, als eine konkrete Klasse. Dann würde ich aber auch zum spezfischsten Interface tendieren.

Ich hatte in einem Projekt eine Codebase, in der oft Collection<> zurückgegeben wurde, obwohl in der konkreten Implementation eine Liste verwendet wurde und ich auch auf die sortierung angewesen wärde. Die Optionen waren dann, nochmal "sortieren" bzw in eine Liste überführen oder die ganze Codebase ändern.

Siehe auch:

Return the most specific type, accept the most generic type

I guess most developers heard the guideline stating that, when designing methods, you should return the most specific type and accept the most generic one. Is it always applicable? Let’s try to look at it from different perspectives.

enterprisecraftsmanship.com

 

[KonradN]

Das ist doch ein guter Ansatz. (Ändert aber nichts daran, dass da ein Entwickler das Framework schreibt und dass dieser einfach nur die Anforderungen umsetzt. Die Anforderungen sind nur etwas umfangreicher):

Also schau einfach einmal Libraries / Frameworks an. Spring, Quarkus, .... Welche Library soll es sein? Vielleicht bleiben wir auch einfach beim Java Framework? Was wird denn da so als Rückgabe verwendet?

@thecain Bitte jetzt in die letzten Posts nichts falsches hinein interpretieren! Hier geht es explizit um List vs ArrayList! Bei Rückgabetypen war schon klar, dass man da möglichst genau bleibt - bei den Interfaces! So dies möglich ist! Also wenn ich eine List habe, dann gebe ich diese auch zurück. Da würde ich ohne sehr guten Grund nie auf Collection oder Iterable zurück gehen! Das ist also komplett unbestritten und war in #17 so ja abgehakt:

Aber die Kernaussage ist richtig: Wenn Du eine Liste zurück gibst, dann gibst Du eine Liste zurück -> List. Da musst Du also nicht überlegen, ob evtl. eine Collection oder Iterable ausreichen würde (Du kennst die Verwendung ja nicht!). Bei einem Parameter kennst Du die Verwendung aber. Und da macht es dann Sinn, sich genau zu überlegen, was man dann braucht. Und wenn Du nur ein Iterable brauchst, dann nimmst Du keine List als Parameter.

 

[KonradN]

@Neumi5694: Du gibt @thecain ein Like? Dir ist aber bewusst, dass er unter dem Strich nichts anderes schreibt als ich die ganze Zeit?

Für die Stabilität zu gewährleisten, macht es mMn auf jeden Fall Sinn eher ein Interface zurückzugeben, als eine konkrete Klasse.

Das Andere, was er schreibt, war in #17 schon längst abgenickt und war gar kein Thema mehr! Du hast nur eben immer auf die AraryList bestanden statt das Interface List zu nutzen ....

 

[Neumi5694]

@Neumi5694: Du gibt @thecain ein Like? Dir ist aber bewusst, dass er unter dem Strich nichts anderes schreibt als ich die ganze Zeit?



Das Andere, was er schreibt, war in #17 schon längst abgenickt und war gar kein Thema mehr! Du hast nur eben immer auf die AraryList bestanden statt das Interface List zu nutzen ....

Gegenfrage: Wie oft willst du immer noch die beleidigte Leberwurst spielen, dich aus einem Thread verabschieden und dann doch weiterposten?

Sein erster Absatz befürwortet Interfaces, der Rest und vor allem der Link stimmen mit meinem Prinzip überein (also das genaue Gegenteil von dem, was du geschrieben hast). Und dafür den Like.
Edit: Außerdem war sein Post besser geschrieben als unsere, ohne die typische Rechthaberei.

 

[KonradN]

Gegenfrage: Wie oft willst du immer noch die beleidigte Leberwurst spielen, dich aus einem Thread verabschieden und dann doch weiterposten?

Ja, es kommen halt doch immer wieder Punkte, wo ich meine, dass man da den Ansatz hätte, das Missverständnis aufzuzeigen.

Und ja - ich bin in keiner Weise konsequent. Das habe ich doch schon mit der Erstellung dieses Accounts bewiesen.

 

[Neumi5694]

Ja, es kommen halt doch immer wieder Punkte, wo ich meine, dass man da den Ansatz hätte, das Missverständnis aufzuzeigen.

Und ja - ich bin in keiner Weise konsequent. Das habe ich doch schon mit der Erstellung dieses Accounts bewiesen.

Ok, wie wär's mit einer Friedenspfeife? (ernst gemeint)

 

[KonradN]

Ok, wie wär's mit einer Friedenspfeife? (ernst gemeint)

Ich bin Dir in keiner Weise böse oder so. Du hast Deine Meinung und das ist ok. Ich habe versucht Argumente zu bringen, Dinge zu erläutern. Dann wollte ich es dabei sein lassen und dann lieferst Du einen erneuten Ansatz, wo man evtl. ansetzen könnte ... Wenn ich Dir böse wäre oder so, dann würde ich da ja nicht mehr Antworten. Dann wäre die Anzahl der Arschlöcher um 1 größer geworden und ich hätte nicht mehr geantwortet oder so ...

Du bist ja auch vernünftig und ich denke ja auch, dass Du guten sauberen Code schreiben willst. Und da will ich doch auch nur helfen mit Abwägungen und Erläuterungen. Ob ich da Recht habe oder nicht, ist dabei egal. Wenn ich nicht Recht habe, dann lerne ich etwas dazu - dann hätte der Thread mir auch was gebracht.

Aber wir drehen und scheinbar nur im Kreis bzw. ich kriege das (vermeintliche) Verständnisproblem nicht gepackt. Und dann sind wir plötzlich wieder 20 Posts zurück.

Und das nervt mich. Sowas kann ich derzeit nicht ab. Das werfe ich Dir oder Joreyk in keiner Weise vor. Nur eben bleibt der Fakt, dass es mich schlicht nervt. Und das ist es einfach nicht wert. Und daher dann auch schlicht das Ziehen von Konsequenzen...

 

[mihe7]

@KonradN, wie war das nochmal mit der Liste? 🍿

 

[KonradN]

@KonradN, wie war das nochmal mit der Liste? 🍿

Hmm... welche Liste meinst du, wenn du von DER Liste redest?

Meine Frau hat eine Einkaufsliste geschrieben. Willst du dazu mehr erfahren?

Also das Wichtige ist wohl: Bier ist auch auf der Liste ... Du kannst also vorbei kommen um dann ein warmes Bier aus einem Holzteller zu trinken (also ganz unfähig, neues zu lernen, bin ich dann doch noch nicht... )

 

[mihe7]

Wobei jetzt die Frage wäre, heißt es dann

class Wife {
    List<?> getShoppingList() { ... }
    // oder
    ShoppingList getListOfItemsWhichYouHaveToBuyIfYouDontWantToGetInTrouble() { ... }
}

?

 

[Gelöschtes Mitglied 65838]

Wobei jetzt die Frage wäre, heißt es dann

class Wife {
    List<?> getShoppingList() { ... }
    // oder
    ShoppingList getListOfItemsWhichYouHaveToBuyIfYouDontWantToGetInTrouble() { ... }
}

?

damit würdest du aber frauen als objekte darstellen... ohoh... da werden probleme kommen

 

[mihe7]

damit würdest du aber frauen als objekte darstellen... ohoh... da werden probleme kommen

Ja, mein Gott, objektorientierte Sichtweise halt.

 

[KonradN]

@mihe7 aber zum Thema positionieren willst Du Dich nicht? List oder ArrayList - was soll denn nun ein Entwickler zurück geben? Dein warmes Bier musst Du Dir schon noch verdienen!

 

[mihe7]

Ich verfahre nach dem Grundsatz "so abstrakt wie möglich, so konkret wie nötig/sinnvoll", heißt in der Regel, dass ich List zurückgebe.

Damit habe ich auch kein Problem, warum auch? Die List definiert die Semantik und fertig. Einzig die Frage, ob modifiable oder nicht, bleibt beim Interface zur Übersetzungszeit ungeklärt. Das stellt sich mir aber nicht als großes Problem dar, denn die Einsatzmöglichkeiten ergeben sich sowieso nur aus dem Kontext (Methodennamen, Doku).

Würde ich umgekehrt z. B. ArrayList zurückgeben, habe ich einen Vertrag, der den Nutzern der Klasse eben genau dies zusichert. Will ich das ändern, habe ich ein Problem, wenn sich die Clients darauf verlassen haben.