Moin,
ist es möglich bei einer Zahlen If Abfrage einen Vektor abzufragen? Also siehe Code:
public void gibTrend()
{
if _trend = (1, -1, 0)
{
return (_abgenommen, _zugenommen, _gleich);
}
}
Also um zu verhindern, dass man 3 Mal if schreiben muss, soll die Variable _trend Überprüft werden und je nach dem der entsprechende Wert ausgegeben werden.
Jein, Du kannst die Zahlen als keys und die strings als Values in eine Map stecken und dann deren get-Methode benutzen
trends.put(-1,"_abgenommen");
trends.put(0,"_gleich");
trends.put(1,"_zugenommen");
};
public String gibTrend(int zahl)
{
return trends.get(zahl);
}
Bei einer so kleinen Wertemenge bietet sich auch die Nutzung einer Enum statt der Strings an:
ABGENOMMEN, GLEICH, ZUGENOMMEN;
private staic final Trends[] trends = Trends.values();
public Trend gibTrend(int zahl) {
return trends[zahl + 1];
}
}
Btw,
Map<Integer, String> trends = new HashMap<Integer, String>();
funktioniert leider nicht.
Und dann so etwas:
return map.get(key); // hier String
} else { // else { eigtl. nicht notwendig
return null;
}```
Wenn die Werte für key aufsteigend, und ohne "Lücken"/aufeinanderfolgend, sind (und mit 0 beginnen) und eine feste Größe/Länge habn, dann einfach ein `String[]`.
`gibTrend` braucht auch einen "passigen" Rückgabetyp. Fast Advent heute.Auch wenn’s mir schwer fällt: hier wäre womöglich ein switch sinnvoll:```interface Trend{
int ZUGENOMMEN = 1;
int GLEICH = 0;
int ABGENOMMEN = -1;
}
public String gibTrend(int zahl) {
switch (zahl){
case Trend.ABGENOMMEN;
return “_abgenommen”;
case Trend.GLEICH;
return “_gleich”;
case Trend.ZUGENOMMEN;
return “_zugenommen”;
default:
throw new IllegalArgumentException(zahl+" ist kein Trend");
}
}```
bye
TT
@TO
Naja, als return-Type “void” wenn man etwas returnen will macht natürlich keinen Sinn. Du musst schon definieren von welchem Type die Objekte sind die im return stehen.
Zum IF-Konstrukt selbst : selbst wenn das so gehen würde wäre keinerlei Beziehung zwischen if() und return gegeben. Es gäbe also keine eingebaute Funktion die so arbeiten würde das wenn der 3. Teil des if() true ist dann auch der 3. Teil des return ausgeführt werden würde. Und ich kann mir auch nur schwer vorstellen das es andere Sprachen gibt bei denen das so wie du es dir vorstellst möglich wäre.
Wenn du auf Grund eines bestimmten Umstandes (einer Condition) halt etwas dazugehöriges returnen willst musst du entweder für jeden Fall ein eigenes if()-return schreiben (was jetzt erstmal nicht weiter wild ist) oder andere Strukturen wie switch() oder Map nutzen. Auch sollte man drauf achten den Code halbwegs leicht wartbar zu schreiben. Auch wenns nur für dich selbst ist und somit niemand das je zu sehen bekommen wird solltest du dran denken das du es später vielleicht mal erweitern, modifizieren oder wiederverwenden willst.
Außerdem solltest du dir mal die Naming-Conventions ansehen: führende “_” macht man in Java nicht.
@CB
Naja, nur weil wir nicht wissen von welchem Type “_abgenommen” und die anderen sind wäre halt als pseudo lediglich Map<Integer, Object> sinnvoll, aber warum soll es gar nicht funktionieren ? Ich kenn mich zwar mit HashMap nicht aus, aber denke doch das ein Integer als Key möglich sein sollte.
Sonst erklär mal bitte was genau du meinst was da nicht funktionieren soll.
Und auch dein if-Konstrukt … völlig überflüssig. Warum erst prüfen ob “key” in “map” enthalten ist und bei false “null” returnen wenn Map.get() bereits genau DAS macht ? Das ist unnötiges “doppel-gemoppel”.
Das soll keine Kritik an deiner Person sein, aber selbst mir mit langer Erfahrung ist leider unklar was genau du sagen willst, und ein Anfänger dürfte komplett verwirrt sein.
@TT
Auch wenn ich Fan von Interfaces bin geht ein reines “Konstanten-Interface” doch etwas weit, wäre allerdings sinnvoll wenn man halt mit einem “Trend”-Objekt arbeiten würde.
Aus Neugier: Wo kommt der Wert -1,0,1 her, und wo soll das Ergebnis dieser Funtkion hingehen? Es böte sich idiomatischerweise an, diese Trend-Werte analog zu den Rückgabewerten eines Comparators zu machen: https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#compare-T-T-
-1 : Abgenommen
0: Gleich geblieben
1: Zugenommen
(achtung, der Comparator legt sich nicht auf -1/1 fest, sondern nur auf <0 und >0)
Und was soll das Ergebnis sein? Ein String? (Ansonsten gibt es kaum eine “Repräsentation” dieses Sachverhaltes, für die nicht -1,0,1 die angebrachteste wäre…)
Also btw heißt nebensächlich oder nebenbei bemerkt.
Ich kenne mich mit generics diamonds Theorie nicht aus. Das ist ja eine zusätzliche statische Typisierung- und Sicherheit.
Nun stellt sich folgendes Probl:
Generic type parameter innerhalb “generic”.
Map<String, String> map; ist ja kein Probl, eine Map, dessen/deren keys und values Strings sind, und aus einem String kann ja “leicht” der hash berechnet werden. Jeder key (/hash) darf höchstens einmal vorkommen, values (und null) aber öfter/s.
Was hat das mit der Fragestellung zu tun? Nur, dass man eine Map verwenden kann. Wieso if-else-?, yagni, aber so könnte man noch erweitern, bereits vorhandene Elems zu erweitern (Elems an eine map value list anhängen, wenn der value bereits vorhanden).
Bei interface Trend musst du noch beachten, dass implizit alle “Variablen” public static final sind (Konstanten sozusagen). Also eigentlich eine elegante Schreibweise.
So, map wurde genannt, enum wurde genannt, Konstante(n) wurde genannt und switch wurde genannt (immer viel Overhead). Mehr gibt’s nicht, das muss als Inspiration reichen. Grüße an alle.
[ot]Generics sind invariant, deshalb braucht man bei der Typdeklaration auf der linken Seite Map<String, ? extends List<String>>, damit das kompiliert. Abgesehen davon solltest du auf der rechten Seite aber List<String> verwenden… Wenn du das nicht tust, dann hast du bei der Verwendung deiner verschachtelten Liste später Probleme.[/ot]
[QUOTE=CyborgBeta]Btw,
Map<Integer, String> trends = new HashMap<Integer, String>();
funktioniert leider nicht.
[/QUOTE]Das funktioniert wunderbar. Was nicht funktioniert ist:
Map<int, String> trends = new HashMap<int, String>();Man beachte den Unterschied zwischen Integer (funktioniert mit Generics) und int (funktioniert nicht).
Folgende switch-Lösung würde wohl obigen Code am nächsten kommen:
case -1: return "abgenommen";
case 0: return "gleich";
case 1: return "zugenommen";
}```Also innerhalb generischer Typparameter ist keine Typpolymorphie erlaubt, sondern das muss explizit geschrieben werden, und Nicht-Wrapper-Typen und -Referenzen sind auch nicht erlaubt, da mindestens ein super class type zur compile time bekannt sein muss. Man will ja Klassen wie eine nicht heterogene Liste schreiben, ohne jetzt/dabei Reflections zu verwenden.
Wenn man noch Marcos Post beachtet und nicht nur bis Java 7 denkt, dann wäre noch funktionale Programmierung mit ihren speziellen Methoden und Rückgabewerten eine Möglichkeit. Cheersy. 
[QUOTE=CyborgBeta]Btw,
Map<Integer, String> trends = new HashMap<Integer, String>();
funktioniert leider nicht.[/QUOTE]
Ich möchte ja nicht böse klingen, aber genau wie @Natac hätte ich bitte gerne mal eine Antwort auf die Frage : „WAS soll daran nicht funktionieren?“.
Den Unterschied zwischen der Wrapper-Klasse java.lang.Integer und dem primitiven Datentyp int hat er ja bereits erklärt.
Auch wenn Java8 da einige neue Sprachelemente eingebracht hat bleibt es trotzdem weiterhin eine Objekt-orientierte Sprache. Vorsätzlich prozedural/funktional zu programmieren widerspricht dem, auch wenn es sicher ein elementarer Bestandteil eines jeden Programmes ist was Befehl für Befehl sequentiell abgearbeitet wird.
Arg, nicht verwechseln, imperative oder prozedurale Programmierung != funktionale Programmierung (mit z. B. Lambda-„Funktionen“).
Es ist übersichtlicher, einfacher (kürzer) und besser (sicherer), Klassen und Objekte (mit z. B. Konstruktoren und Attributen) zu schreiben, das stimmt, aber ich bekomm’ schneller Ergebnisse, wenn ich „alles“ static mache/deklariere/„definiere“. 
Jeder, wie er möchte. Manchmal schmiert mir dabei java -jar aus unerklärlichen Gründen auch ab.
Stimmt so nicht, nein. Du schaffst dir dadurch nur Mehraufwand und schlecht testbaren Code. Solltest du was geschrieben haben, dass funktioniert, dann kannst du es nämlich umschreiben, damit du es mit Objekten sinnvoll verwenden kannst. Das einzige was dir static erspart, ist das erstellen eines Objektes (einzeiler) - im Gegenzug erhälst du x-Methoden die static sind - was du dann später wieder rausschmeißen kannst. Zudem musst du deine Zustände als Parameter weitergeben oder diese auch in statischen Feldvariablen speichern. Sorgt nachträglich also nochmal für arbeit.
Gut, Unterschied funktional und prozedural/imperativ bin ich nicht so fit. Lass mich gerne belehren.
troll : Eine Antwort bzgl. der “nicht funktionierenden Map” hätte ich trotzdem gerne.
[quote=Sen-Mithrarin]troll : Eine Antwort bzgl. der “nicht funktionierenden Map” hätte ich trotzdem gerne.[/quote]fisch
Generics funktionieren nun mal nicht mit primitiven Zahlentypen, aber sonst beherscht Java-1.5+ “autoboxing”, also die implizite Umwandlung von beispielsweise int nach Integer und umgekehrt.
bye
TT
das war in Posting #9 schon geklärt, in #3 geht es aber normal um Integer statt int,
man kann das Thema natürlich auch längst fallen lassen,
ich beobachte diese Nachfragen am Rande der Löschung, aber wenn es mal sein muss 
Prophezeiung: ‚Fehler war zu anderem Code‘, supi