Variable in einer Schleife initialisieren

[Marcel98]

Hallo ist es mögliche eine Variable in einer Schleife zu initialisieren?
Die "helpFunction.openScannerString()" öffnet einen Scanner der den Wert zurück gibt.
Hier meine Problem:
[CODE lang="java" title="Methode"]public static boolean yesOrNot() {

boolean carryOn = true;
boolean bool;

while(carryOn) {
switch(helpFunction.openScannerString()) {
case "j":
case "ja":
case "yes":
bool = true;
carryOn = false;
break;
case "nein":
case "n":
case "no":
bool = false;
carryOn = false;
break;
default:
System.err.println("Bitte geben Sie Ja oder Nein ein.");

}
}
return bool;
}[/CODE]

 

[httpdigest]

Das Problem ist, dass der Compiler nicht sicherstellen kann, dass die Variable `bool` am Ende beim `return-Statement` auch wirklich einen Wert zugewiesen bekommen hat. Das ist zwar in deinem konkreten Fall _immer_ so, weil es keinen Weg gibt, die Schleife zu verlassen, ohne, dass `bool` nicht true oder false zugewiesen bekäme. Aber, der Kontrollfluss hier ist für den Compiler zu schwierig zu sehen.
Deswegen müsstest du einfach bei der Deklaration von `bool` einmal eine initiale Zuweisung machen, z.B. `boolean bool = false;`

 

[Gelöschtes Mitglied 65838]

z.B. `boolean bool = false;`

???

das ist es automatisch in java

Primitive Data Types (The Java™ Tutorials > Learning the Java Language > Language Basics)

 

[httpdigest]

Nein. Lokale Variablen werden nicht automatisch initialisiert. Nur Felder.
Es ist immer ein Compilefehler, eine nicht explizit initialisierte lokale Variable zu lesen/verwenden.
Aus deiner Referenz:

It's not always necessary to assign a value when a field is declared.

 

[Gelöschtes Mitglied 65838]

public boolean yesOrNot(){
    while(true){
        String input = helpfunction.scannerEingabe();
        if(input.equals("yes")){
            return true;
        } else if(input.equals("no")){
            return false;
        } else{
            System.err.println("blabla")
        }
        
    }
}

du brauchst doch nicht mal ne variable

 

[Marcel98]

die Variable bool ist in diesem fall nicht initialisiert.

 

[Marcel98]

public boolean yesOrNot(){
    while(true){
        String input = helpfunction.scannerEingabe();
        if(input.equals("yes")){
            return true;
        } else if(input.equals("no")){
            return false;
        } else{
            System.err.println("blabla")
        }
       
    }
}

du brauchst doch nicht mal ne variable

Ich möchte mehrerer Möglichkeiten gelten lassen und da kam mir der Gedanke ich könnte alles mit einer Switch Funktion machen. Problem ist nur, ich kann "bool" nicht returnen.

 

[Gelöschtes Mitglied 65838]

Nein. Lokale Variablen werden nicht automatisch initialisiert. Nur Felder.
Es ist immer ein Compilefehler, eine nicht explizit initialisierte lokale Variable zu lesen/verwenden.
Aus deiner Referenz:

oh...

dann muss ich es zurück ziehen, war dann mein fehler... hatte lang kein bool mehr in ner methode deklariert , meistens nur als feld

 

[Gelöschtes Mitglied 65838]

Ich möchte mehrerer Möglichkeiten gelten lassen und da kam mir der Gedanke ich könnte alles mit einer Switch Funktion machen. Problem ist nur, ich kann "bool" nicht returnen.

  if(input.equals("yes") || input.equals("y") ||input.equals("ja" ){

            return true;

        }

einfache oder verknüpfung...

switch cases werden geil zu verwenden wenn man enums hat, zunmindest kommts mir so vor... für alles andere benutz ich ifs ausser das switch bietet sich an... das ist aber nur mein obulus zu dem

 

[httpdigest]

@Marcel98 mach es so wie @Joreyk sagt. Du brauchst keine lokale Variable. Oder, du liest einfach nochmal genau, was ich in #2 geschrieben habe:

Deswegen müsstest du einfach bei der Deklaration von `bool` einmal eine initiale Zuweisung machen, z.B. `boolean bool = false;`

 

[Marcel98]

Danke schön, dachte es geht irgendwie mit einer switch methode.

 

[Gelöschtes Mitglied 65838]

Danke schön, dachte es geht irgendwie mit einer switch methode.

tut es auch.. es gibt immer 10 wege
du warst ja auch nah dran... du hast ja nur ein =false; vergessen

es hat ja niemand gesagt "dein code ist müll", ich wollte dir nur zeigen wie man es auch noch machen kann

nur du musst lernen den für den ersten blick besten zu gehen, du wirst niemals immer den besten gehen, das tut kein programmierer
bei den "basics" solltest du aber immer den richtigen gehen

zb:
ja man kann es mit 2 lokalen variablen lösen => durchs umstellen kann man es ohne 2 lokalen variablen lösen
damit ist der code lesbarer ... stell dir vor du machst mal was komplexeres.. dann hast irgendwann 10 lokale variablen und schon puff.. kennt sich niemand mehr aus => blöd

deswegen gleich kleine tricks lernen um gleich mehr zu lernen


es gibt noch paar andere sachen was ich dazu sagen könnte aber ...

 

[Neumi5694]

Danke schön, dachte es geht irgendwie mit einer switch methode.

Natürlich geht's auch mit Switch, aber du musst jeden Fall abdecken. In deinem default-Fall weist du keinen Wert zu.
Der Compiler erkennt das und meldet, dass die Variable nicht gesetzt ist (bei if-elseif-else müsstest du auch was im else-Fall stehen haben).

Wenn du mit so was arbeiten willst, dann brauchst du zumindest ein TriState-Enum, z.B. {Confirmed,Denied,Undefined}.

Was den Standard-Wert von boolean angeht: Ja, effektiv ist eine ungesetzte boolean-Variable schon bei Deklaration auf false, aber der Compiler unterstützt sauberes Programmieren und prüft, ob sie vor dem ersten Zugriff auf jeden Fall einen Wert durch eine Zuweisung erhalten hat.
In einigen wenigen Fällen versagt die Erkennung des Compilers, aber er ist im Allgemeinen schon ziemlich zuverlässig.

 

[KonradN]

Danke schön, dachte es geht irgendwie mit einer switch methode.

Es geht doch so, wie Du gesagt hast. Daher einfach einmal an Deinem Code aufgezeigt, was @httpdigest meinte:
[CODE lang="java" highlight="4"]public static boolean yesOrNot() {

boolean carryOn = true;
boolean bool = false;

while(carryOn) {
switch(helpFunction.openScannerString()) {
case "j":
case "ja":
case "yes":
bool = true;
carryOn = false;
break;
case "nein":
case "n":
case "no":
bool = false;
carryOn = false;
break;
default:
System.err.println("Bitte geben Sie Ja oder Nein ein.");

}
}
return bool;
}[/CODE]

Oder eben ohne die Variable bool:

public static boolean yesOrNot() {
        while(true) {
            switch(helpFunction.openScannerString()) {
                case "j":
                case "ja":
                case "yes":
                    return true;

                case "nein":
                case "n":
                case "no":
                    return false;
                
                default:
                    System.err.println("Bitte geben Sie Ja oder Nein ein.");
        }
            }
    }

Also switch ist möglich, dein Problem lag nur schlicht an etwas anderem - siehe Erklärung von @httpdigest

 

[Gelöschtes Mitglied 65838]

public static boolean yesOrNot() {
        while(true) {
            switch(helpFunction.openScannerString()) {
                case "j":
                case "ja":
                case "yes":
                    return true;

                case "nein":
                case "n":
                case "no":
                    return false;
             
                default:
                    System.err.println("Bitte geben Sie Ja oder Nein ein.");
        }
            }
    }

Also switch ist möglich, dein Problem lag nur schlicht an etwas anderem - siehe Erklärung von @httpdigest

aber warum soll man das tun ?

1. man hardcoded die möglichen cases, hinzufügen kann zu verwirrung führen... oder ein blöd gesetztes break zerschießt den code
2. es ist schwer lesbar... wenn ich das in ein if packe, die bedingung auslagere in eine methode hab ich zb

if(hasYesParts(input))...
    else ( hasNoParts(input))...

das ist besser lesbar und wenn zb der code dann bei einer stelle sich unerwartet verhaltet muss ich zb nur in der bedingungs methode nachschauen was da nicht passt ... ansonsten msus man immer überprüfen ob man überhaupt an der richtigen stelle ist und ob man nicht das ganze verhalten zerschossen hat

EDIT: zusätzlich könnte man dann ein array anlegen für alle möglichen yes teile... dann looped man nur über das yes array drüber dh wenn ich die cases erweitern will schau ich mir gar nicht die methode an sondern fügs einfach nur dem array ein wert hinzu und es wird im regelfall immer noch funktionieren

 

[Neumi5694]

ps: In Java16 gibt's eine schöne Methode, um eine einzelne Variable durch switch sauber zuzuweisen, dadurch kann man viele Fehler vermeiden

SomeType variable = switch (stringOption) {
        case "yes","ja" -> FixerWertOderMethodenAufruf;
        case "no","nein" -> {
            //Irgendeine Berechnung
            yield Ergebnis;
        };
        default ->  FixerWertOderMethodenAufruf;
};

 

[Neumi5694]

aber warum soll man das tun ?

Besser wäre natürlich eine ordentliche Auswertung, schon allein wegen der Groß-Kleinschreibung (es sei denn man transformiert vorher den Sting nach LowerCase), aber grundsätzlich ist die Methode schon ok, wenn dieses eine Beispiel auch schöner gelöst werden könnte.,

 

[KonradN]

aber warum soll man das tun ?

Wenn die Anforderung genau diese Auflistung der Elemente ist, dann ist dies die sauberste Variante.

Die Frage ist also, was für Anforderungen man hat. Massive Aneinanderreihungen von equals Aufrufen und mehrere ifs sind aber extrem schlechter stil und schwer zu lesen.

die bedingung auslagere in eine methode

Dazu müsste man das erst einmal sauber strukturieren und da wirst Du vermutlich wieder zu ähnlichen Lösungen kommen. Dein Vorgehen ist in meinen Augen explizit KEINE sauber Lösung (mit den vielen equals).

a) switch schlägt die Aneinanderreihung von Prüfungen mit mehreren ifs
b) switch kann man oft - gerade bei dynamischen Sachverhalten - durch Datenstrukturen ersetzen.

Also wäre hier z.B. eine Map denkbar:
"yes" -> true
"y" -> true
"ja" -> true
"j" -> true
"no" -> false
"n" -> false
...
Und schon wird das alles nur noch eine reine Abfrage der Map.

Das nur um die "üblichen" Refactorings, die man sehr oft finden kann, anzusprechen.

Das wäre meine bescheidene Sicht auf diese Thematik. Soll aber jeder so machen, wie er es für richtig hält.

 

[Gelöschtes Mitglied 65838]

es sollte ja dann auch ein array raus gezogen werden dass ich keine equalse mehr hab in der menge... das war auch mit dem "aber..." gemeint.. TE wirds wahrscheinlich eh nur halb mitnehmen... dann ist es die klassiker diskussion zwischen dir mir, oneixxe, robert limdul, neumi... und IRGEND jemand der das über java diskutieren kaputt macht

String[] yesParts = {"Yes"...}
String[] noParts = {"NO"...}
private boolean hasYesParts(String input){
    return checkParts(input, yesParts)
}
private boolean hasNoParts(String input){
    return checkParts(input, noParts)
}
private boolean checkParts(String input,String[] partsArray){
    for(var part : partsArray){
        if(input.equals(input)) return true
    }
    return false;
}

@KonradN

 

[KonradN]

es sollte ja dann auch ein array raus gezogen werden

Ok, das habe ich dann evtl. überlesen oder so nicht verstanden. Dann geht es ja doch genau in die Richtung, die ich dann auch skizziert hatte. Nur eben das als Datenstruktur etwas verwendet wurde, das eben das Nachschlagen direkt vereinfacht, so dass man sich den Code sparen kann. Also die Schleifen mit den Vergleichen entfällt ebenso wie der Code der die einzelnen Prüfungen macht, da es komplett in einer Abfrage auf der Datenstruktur bleibt.

Und das mit den Diskussionen: Es ist aus meiner Sicht ok, sowas so zu vertiefen. Das ist ja durchaus interessant, andere Meinungen zu hören, wobei hier es wohl so ist, dass wir unter dem strich eigentlich sehr eng zusammen lagen. Das sind dann durchaus angenehme Gespräche. Maximal noch ein Report absetzen - dann kann sich @mrBrown (oder natürlich ein anderer Moderator) überlegen, ob er es abspaltet.

 

[Gelöschtes Mitglied 65838]

bei den Datenstrukturen kommt es halt drauf an wie weit derjenige ist.. da der TE schonmal ein problem mit Objekten hatte, dachte ich dass ich nicht gleich drauf hauen kann wie zb mit einer Liste oder sonst was weil die Grundkenntnisse und Verständnis da sind aber noch nicht genug geübt.. war zumindest meine Einschätzung, kann aber auch daneben liegen

 

[KonradN]

bei den Datenstrukturen kommt es halt drauf an wie weit derjenige ist..

Daher bin ich ja auch noch bei den Switch geblieben. Gute und korrekte Anwendung. Dies Refactorings würde ich nicht machen. Nur eben würde ich so halbe Dinge auch nicht angehen. Das verwirrt doch erst einmal auch nur. An der Stelle ist erst einmal wichtig, dass der TE versteht, was denn das Problem an seinem Code ist.

Eine alternative Lösung führt zu keinem Lerneffekt. Was hat er denn dann gelernt? Mit Switch geht das nicht? Daher wäre es - zumindest aus meiner Sicht - wünschenswert, wenn man erst die Probleme aufzeigt und erläutert und erst danach Alternativen bringt.

 

[Marcel98]

Besser wäre natürlich eine ordentliche Auswertung, schon allein wegen der Groß-Kleinschreibung (es sei denn man transformiert vorher den Sting nach LowerCase), aber grundsätzlich ist die Methode schon ok, wenn dieses eine Beispiel auch schöner gelöst werden könnte.,

der Input vom User wird in der Scanner Methode bearbeitet.(.LowerCase)

 

[Neumi5694]

der Input vom User wird in der Scanner Methode bearbeitet.(.LowerCase)

Dann mach dir das Leben einfach, indem du die Eingabe für die Auswertung entweder in Groß- oder Kleinbuchstaben konvertierst, dann musst du bei switch/case keine Variationen berücksichtigen.

Zu der Variante mit 3 Möglichkeiten (ja/nein/unbestimmt) ist mir noch was eingefallen, was Jave für solche Fälle bereitstellt: Optional.

Ich werde nicht behaupten, dass das hier ist die beste Möglichkeit, aber es wäre eine Option.

public boolean yesOrNot(){
    Optional<Boolean> optional;
    do {
        System.out.println("Bitte geben Sie Ja oder Nein ein.");
        optional = switch (helpFunction.openScannerString().toLowerCase()) {
            case "yes","ja","y","j" -> Optional.of(true);
            case "no","nein","n" -> Optional.of(false);
            default -> Optional.empty();
        };
    } while (optional.isEmpty()); //so lange es keine gültige Eingabe gab, hat optional keinen Wert.
    //oder  while (!optional.isPresent())
    return optional.get();
}

Edit: Hab's nochmal etwas gestrafft

 

[Gelöschtes Mitglied 65838]

String[] yesParts = {"Yes"...}
String[] noParts = {"NO"...}
private boolean hasYesParts(String input){
    return checkParts(input, yesParts)
}
private boolean hasNoParts(String input){
    return checkParts(input, noParts)
}
private boolean checkParts(String input,String[] partsArray){
    for(var part : partsArray){
        if(input.equals(input)) return true
    }
    return false;
}
public boolean YesOrNo(){
    while(true){
        String input = help.inputLesen();
        if(hasYesParts(input)) return true;
        else if(hasNoParts(input)) return false;
        else{ System.err.println("bob"); }
    }
}

das wäre meine lösung.. hab aber grad kein eclipse zur hand für syntax zeug

 

[Gelöschtes Mitglied 65838]

List<String> yesParts = {"Yes"...}

List<String> noParts = {"NO"...}

private boolean hasYesParts(String input){

    return yesParts.contains(input)

}

private boolean hasNoParts(String input){

    return  noParts.contains(input);

}

public boolean YesOrNo(){

    while(true){

        String input = help.inputLesen();

        if(hasYesParts(input)) return true;

        else if(hasNoParts(input)) return false;

        else{ System.err.println("bob"); }

    }

}

wäre dann wieder einen schritt weiter und immer noch lesbarer als irgend ein switch... plus man zershcießtt nix mehr so einfach

ja die methoden noparts usw schauen einfach aus.. aber man kann sie testen wenn auch nur über reflection wenn mans private hat .. aber testbar

 

[KonradN]

Also wir sind sind vom Thema des Threads doch eigentlich weit weg, daher ist das eigentlich Off Topic. Aber nur mal für Dich weil ich denke, dass es für Dich interessant ist (Wenn nicht, dann sag es einfach, dann kann ich mir meine Zeit sparen. Ich muss niemanden überzeugen.):

aber man kann sie testen wenn auch nur über reflection wenn mans private hat

Etwas Spaß: Bist Du schwerhörig? Batterien vom Hörgerät leer? Das schreit doch so sehr nach Refactoring, dass es in den Ohren weh tut. Da muss es doch Probleme mit dem Arbeitsschutz geben oder ist Gehörschutz bei euch im Büro vorgeschrieben?

Sorry für den Spaß. Aber das ist einfach nur ein typisches Zeichen, dass da etwas nicht stimmt (Ein Code Smell). Etwas ist nicht so einfach testbar, also ist es so schlicht falsch. Klar, hartes Wort, aber aus Clean Code Sicht ist das leider durchaus die Klassifizierung. Auchgut erkennbar, dass eben etwas nicht "einfach" und "dumm" ist. Also ganz offensichtlich kein KISS (Keep It Simple, Stupid) angewendet.

Du hast ein Verhalten (also eine Methode in Java), welche abe kein Verhalten der Klasse selbst ist. Daher willst Du es verstecken. Also ist die Frage: Von was ist denn dieses Verhalten? Denn in die Klasse gehört es dann ganz offensichtlich. Du hast dann also eine Klasse, die Antworten Auswerten kann. YesNoEvaluator oder wie auch immer. Und das hat dann ein entsprechendes Verhalten. Und schon ist dieses Verhalten in Unit Tests testbar. Natürlich ohne Reflection.

Ein anderer Punkt ist dann natürlich noch etwas das DRY (Don't Repeat Yourself) - evtl. etwas hart die Auslegung, aber das fällt mir da etwas ins Auge. Ganz offensichtlich hast Du zwei Dinge, die gleich sind:
Zwei String Liste und zwei Methoden, die da ein einfaches Contains aufrufen.

Also dann doch den letzten Schritt auch noch gehen hin zur Map. Dann hast Du eine Map mit Werten. Und wenn man sich das dann nur ein klein wenig überlegt, dann kann man relativ schnell zu einer einfachen Translator Klasse bauen. Das wäre dann z.B. sowas wie (ungetestet, Idee nur skizziert):

public class Translator<K,V> {
    Map<K,V> valuePairs;

    public Translator(Map<K,V> valuePairs) {
        this.valuePairs = valuePairs;
    }

    public Optional<V> translate(K key) {
        return Optional.ofNullable(valuePairs.get(key));
    }
}

Aufbauen könnte man dann so einen Translator z.B. mit sowas:

        var yesNoTranslator = new Translator(
                Map.of(
                        "yes", true,
                        "y", true,
                        "no", false,
                        "n", false));

Oder man erbt davon:

public class YesNoTranslator extends Translator<String, Boolean> {
    public YesNoTranslator() {
        super(
                Map.of(
                        "yes", true,
                        "y", true,
                        "no", false,
                        "n", false));
    }
}

Die Verwendung selbst ist dann ein einfacher Aufruf und man hat dann wieder ein einfaches Switch das die möglichen Werten enthält und dann jeweils etwas macht bzw. hier im Beispiel des Threads einfach eine while Schleife, die so lange läuft wie der Wert einer Variable Optional.empty ist um sonst den Wert des Optional zurück zu geben.

Aber die Klasse kann für beliebige Dinge genutzt werden. Also z.B. auch für die Übersetzung von Dingen, die kein String sind hin zu beliebigen Enums oder anderen Werten. Wenn Dir die Art der Map, die übergeben wird, nicht gefällt, dann kann man das auch gerne umstellen. Man könnte also den Konstruktor verändern, der dann die Ziel-Map neu aufbaut und übergeben tut man eine Map<V, List<K>>. Dann muss man nur einmal das true angeben mit der Liste aller true Werte.

Deutlich universeller nutzbar, einfach in Unit Tests testbar, u.s.w.

Aber: Wie schon am Anfang gesagt: für den Thread so eigentlich nicht mehr von Interesse. Und es ist unter dem Strich nur das, was ich schon erwähnt habe: Map wäre hier die zu bevorzugende Collection für die Werte.

 

[Gelöschtes Mitglied 65838]

wenn ich SOLID durchziehe dass ich klassen raus ziehe dann hab ich immer mehr public methoden als vorher
@KonradN hast ja auch aus einer private eine public gemacht aber dann endet das ja ansich mit 3/4 des codes ist public oder nicht ?

mein prof an der uni hat gesagt
"bevor man ungerechtfertigt aus einer private eine public mehtode macht sollte man lieber über reflection den test machen"

dann kommt was ich nicht versteh bei so SOLID anwenden
ich hab 1e klasse die refactored werden muss
=> ich zieh 3 klassen raus
=> für jedes dieser 3 Klassen muss ich das interface raus ziehen für das interface segregation principle dings bumms
=> dann hab ich 7 klassen insgesamt

ich bin zu sehr in unity im moment mit c#...
da ist es so dass man an objekten in dem szene graph skripte "anhängen muss"
zb ich klipse die nicht refactored klasse ran dass ich dem objekt die funktionalität geb
so dann mahc ich das refactoren und schwups muss ich 4 skripte anklipsen

oder ein anderes beispiel
in javafx
die

ReadonlyDoubleWrapperProperty readonlyDoubleWrapperProperty = new SimpleReadonlyDoubleWrapperProperty();

versuch mal das 3 mal schnell hintereinander zu sagen
da wurde es auch komplett übertrieben mit interface und abstraktionen dass es gerade so raucht.. hab noch keinen gehört der sich dachte
"ja gottseidank gibts die readonlyDoubleWrapperProperty"
den ganzen property schmarn hätte man auf die ObjectProperty runter kürzen können da ich zb auch einfach machen kann

ReadonlyObjectProperty<Double> ...

die primitiven datentypen sind dadurch schon abgedeckt da ich einfach die Wrapper benutzen kann der Datentypen


und die anderen 20 arten von propertys hab ich in meiner javafx zeit NIE benutzt.. für ein Text label zb einfach als referenz dann eine "ObjectProperty<String>" benutzen und gut ist

ObjectProperty<???>
ReadonlyObjectProperty<???>

hätten gereicht dann kapiert man es auch... was bringt es mir wenn man die perfektion von ausarbeitung hat in hinsicht auf clean code
wenn die leute die es hernehmen sich nicht logisch erklären können worums überhaupt geht

witzigerweise erbt die ganze property sache in javafx von irgend einer java bibliothek die als "deprecated" gekennzeichnet ist.. ob das schlimm ist wies ich nicht
hier könnte man dann sogar noch vom kürzen weiter runter gehen und einfach sagen

Property<???>
ReadonlyProperty<???>

dann kapiert mans auch

wenn man halt ein programm refactored und in dem obigen beispiel in 4 aufteilt dann krieg ich zb in unity an einer anderen stelle aufs maul ... also der rückschlag bei ungeplantem refactoring ist ja schon groß wenn mans versaubeutelt.. und die größte versaubeutelung von Abstraktion und hierarchie und interfaces ... sind in meinen augen die javafx properties


das sind halt so probleme die ich seh und die ich in deinem welcome back thread auch gemeint hatte mit "die versteh ich noch nicht" und ich kriegs auch noch nicht so gebacken dass der code dann halbwegs optimal ist... wenigstens ist meiner lesbar dass man mir sagen kann was ich versaubeutelt hab , was ja schon mal etwas ist

 

[KonradN]

mein prof an der uni hat gesagt
"bevor man ungerechtfertigt aus einer private eine public mehtode macht sollte man lieber über reflection den test machen"

Wenn die Methode kein öffentliches Verhalten der Klasse ist, dann hat es nicht public zu sein. Das ist richtig.
Aber es wird ja auch nicht zu einer public Methode der Klasse sondern zu einer public Methode einer anderen Klasse.

Beispiel Auto: Das Auto hat viele innere Abläufe. Diese sind von Außen nicht steuerbar. Also z.B. was den Motor angeht. Daher ist das Verhalten des Motors natürlich kein Verhalten des Autos. Das Auto bekommt also keine Methode, um z.B. ein Ventil zu öffnen.
Aber natürlich kann das Verhalten in einer eigenen Klasse Motor gekapselt sein. Und so ein Motor ist dann testbar.

=> für jedes dieser 3 Klassen muss ich das interface raus ziehen für das interface segregation principle dings bumms

Wieso das? Was besagt denn das Interface Segregation Principle? Das besagt nicht, dass jede Klasse ein Interface haben muss. Das sind veraltete Überlegungen, die auf die Booch Method zurück geht und dann auch in ersten Versionen von UML drin war. Wenn ich mich an den Quatsch erinnere ... Alles hatte noch einen Controller und ein Interface ... So ein Quatsch. Schau Dir die Klassen in dem Framework an: Sind da überall Interfaces?
Das Principle besagt ja nur, dass Interfaces klein sein sollen, also lieber mehrere Interfaces als ein großes. Also wenn ein Hund bellen, beissen und laufen kann, dann hat es BellenInterface, BeissenInterface und LaufenInterface und nicht ein HundeInterface.
Hier ist der Hintergrund, dass die Interfaces nicht vom Objekt selbst kommen sondern diese werden von den Nutzern definiert. Du hast eine Alarmanlage und da soll es dann bellen. Da braucht es also keinen Hund sondern nur etwas, das ein BellenInterface implementiert. Ohne Clients, die ein Bellen brauchen gibt es auch kein solches Interface.
Das nur als kurze Sätze von meiner Seite. Ich hatte in einem anderen Thread vor kurzem erst einen YT Link zu einer Playlist mit Uncle Bob Videos geteilt - schau Dir die mal in Ruhe an.

Was das JavaFX angeht: Dem kann ich so nicht ganz folgen. Die unterschiedlichen Properties haben durchaus seine Berechtigung. Aber Du musst diese ja auch nicht nutzen wenn Du diese nicht brauchst. Das ist ja die Idee bei so Frameworks: Es wird nicht nur gemacht, was man selbst für sinnvoll erachtet sondern nimmt auch Ideen auf, die andere sich wünschen. Ich bin auch schon über Dinge gestolpert wo ich sogar den Entwicklern ein "Fehler" unterstellen würde. Zulestzt hatten wir hier mal einen Thread zum Thema URL und dem Verhalten der Klasse mit der Auswertung des Hostnamens.

Das wäre dazu meine Sicht - ohne es tiefer analysieren und zu sehr ausbreiten zu wollen.

 

[Gelöschtes Mitglied 65838]

meinte das interface inversoin dependency dingens war gedanklcih wo anders

 

[Neumi5694]

wäre dann wieder einen schritt weiter und immer noch lesbarer als irgend ein switch... plus man zershcießtt nix mehr so einfach

ja die methoden noparts usw schauen einfach aus.. aber man kann sie testen wenn auch nur über reflection wenn mans private hat .. aber testbar

"weiter" und "lesbarer" ist Ansichtssache. Wir sind hier im Bereich vom "ich mag keine switches" und "ich finde switches cool".
Ich für meinen Teil finde es ganz praktisch, dass man an einer überschaubaren Programmstelle alle Optionen sichtbar hat und sofort sieht, was was bewirkt. Außerdem werden doppelt vorkommende Werte von vorneherein ausgeschlossen, der Compiler lässt das gar nicht zu.
Das ist für mich eines der klassischen Beispiele, wo ich ein switch mehreren Unterfunktionen, die einander sehr ähnlich sind, vorziehe.
Alle genannten Lösungen funktionieren, sei es switch/set.contains/Methodenaufruf oder Map.

Als zweit"beste" Lösung würde ich anstatt der Arrays Sets verwenden und mit .contains() abfragen. Aber hier hätte ich das gleiche Problem wie du: Wie vermeidet man von vorneherein, dass Werte in beiden Listen vorhanden sind?

Ich habe nichts gegen Methodenaufrufe, ganz im Gegenteil, sie können die Lesbarkeit ungemein verbessern, aber nicht in diesem Fall, wo mehr als eindeutig ist, was die eine Zeile im Switch macht. Diese eine Zeile durch eine andere zu ersetzen, deren Name so ungünstig gewählt ist, dass man daraus nicht ableiten kann, was sie macht, finde ich keine Verbesserung der Lesbarkeit.

Edit: Untermethoden/Set/Map sind auf jeden Fall dann notwendig, wenn man die Sprache nicht vorgegeben hat und verschiedene Werte prüfen müsste und nich nur die hier vorgegebenen. Switch klappt naturgemäß nur für vorgegebene Werte, für Strings setz ich's eigentlich nie ein (außer bei ActionCommands). Nur für diese eine Aufgabe erscheint es mir sinnvoll.

@KonradN Was das Testen angeht ... ich find's noch ein Manko, dass man z.B. per JUnit private Methoden nicht ohne weiteres Testen kann. Umwege über Reflections sind mir zuwider.

 

[KonradN]

Ok, sorry, dass ich das nicht direkt verstanden hatte. Jetzt verstehe ich Deinen Punkt.

Im Folgenden einmal eine Erläuterung meiner Sichtweise.

Hier beissen sich zwei Forderungen:
a) Dependency Inversion Principle
Dahinter versteckt sich., dass (High Level) Klassen nicht von (Low Level) Klassen abhängig sein sollten sondern von Interfaces und dass Interfaces nicht von Details abhängig sein sollten sondern Details von Interfaces.

b) Ich sehe aber auch immer YAGNI (You aint gonna need it)

Wenn man die typischen Business Applikationen erstellt mit der typischen Datenbank mit Entitities und darauf aufbaen dann ein Business Logic Layer und darauf dann irgendwelche Controller / UIs, dann finden sich immer wieder typische Fälle, wo klar ist: Hier braucht man keine Interfaces:
- Entities haben in der Regel keine Interfaces. Ich habe zumindest noch zu der Klasse Empolyee kein Employee Interface gesehen oder so. (Hier auch wichtig: Die Anforderung zu einem Interface kommt aus meiner Sicht immer von denen, die etwas nutzen wollen! Dazu später noch einmal mehr!)
- Dinge auf oberster Ebene - die werden nicht genutzt - daher auch keine Interfaces. Also der EmployeeController des Rest Service. Da habe ich noch nie ein Interface gesehen und das macht auch keinen Sinn.

Nun wie versprochen meine Sicht auf diese DIP und zu den Interfaces. Wann und wie erstelle ich diese?

Generell erstelle ich nie pauschal irgendwelche Interfaces. YAGNI! So lange ich nicht weiss, ob ich die überhaupt brauche, wird da nichts erstellt!
So schreibe ich also z.B. eine Klasse Dog. Es gibt kein DogInterface (Und wird es so eigentlich auch nie geben). Es gibt keinen Grund, das konkrete Interface, das Dog bietet, komplett auch in ein Interface zu schreiben.
Die Interfaces kommen nur über die Nutzer der Klasse:
- Eine Nutzung von Dog ist, dass er gefüttert (feed) werden kann. Jemand, der einen Hund füttern kann, will aber nicht abhängig sein von der konkreten Implementierung. Daher braucht man hier nun ein Interface. Aber was für ein Interface? Ein DogInterface? Das wohl kaum, denn es wrd ja nur das feed() benötigt. Also gibt es ein Interface Feedable oder so.
- Der Hund soll bellen (bark) können. Also bauchen wir hier auch ein entsprechendes Interface. Aber wieder speziell für diesen Sachverhalt. Die Alarmanlage, die dann den Hund bellen lässt, hat mit dem Füttern ja nichts am Hut. Und statt einem reellen Hund steckt da vermutlich meist auch eine Elektronik dahinter, die dann "bellt". Also wirklich nichts mit DogInterface oder so.
...

Natürlich kann es Fälle geben, wo Interface und Implementierung überein stimmen. Dann ist das Map Interface auch genau das, was man in der HashMap implementiert.
Und in einem Punkt hast du Recht: Es kann durchaus Sinn machen, das Beispiel von mir auf zu dröseln:
- Translator wird ein reines Interface
- Die Implementierung wird zu MapTranslator
- Du kannst dann Deine Implementierung als ArrayTranslator hinzu fügen oder so

Sowas gibt es bei formalistischen Entwicklungen durchaus. Dann werden Regeln gerne so angewendet. Da gibt es dann einen Architekten oder Prof, der einem dummen Programmierer oder Studenten sagt, wie es sein muss. Weil er es so meint und das ohne wirklichen Grund (Es ist eine einfache Formalie.)

YAGNI ist daher sehr wichtig. Nehmen wir wieder das Beispiel:
- Ich habe da jetzt diese Implementierung. Jetzt kommt - entgegen allen Erwartungen - diese neue Implementation. Ich kann es relativ einfach umstellen. Das Interface bekommen 1:1 genu das, was die Klasse hat. Es ist halt eine triviale Klasse. Die Abstraktion ist also einfach. Die Klasse selbst wurde nur umbenannt und implementiert das Interface nun. Damit sind wir aber schon fertig.

Was wir nun noch ändern müssen, sind die Stellen, an denen Instanzen erzeugt werden. Das ist eine typische Sache: Das wenn möglich zentralisieren. DIP schlägt dazu z.B. Praktiken vor (z.B. bei clean-code-developer.de):
- Konstruktorparameter
- Inversion of Control Container
- Dependency LookupDie notwendigen Anpassungen an den Abhängigkeiten fallen also nicht wirklich wild aus.

Daher ist aus meiner Sicht immer der gesunde Menschenverstand gefragt: Braucht man das, was ich da schreibe, denn überhaupt?

@KonradN Was das Testen angeht ... ich find's noch ein Manko, dass man z.B. per JUnit private Methoden nicht ohne weiteres Testen kann. Umwege über Reflections sind mir zuwider.

Dazu ist meine Meinung halt ganz klar: Code Smell. Eine private Methode zeigt, dass Deine Klasse in Verhalten hat (Methoden machen ja irgendwas und daher ist es ein Verhalten), das schlicht kein Verhalten Deiner Klasse ist (Weil das Verhalten ja eigentlich durch die von außen aufrufbare Methoden bestimmt wird).

Daher ist die Frage immer: Was für eine provate Methode hast Du da? Ist da ggf. ein Refactoring angebracht und dieses Verhalten kommt in eine eigene Klasse? Dann hast Du eine Klasse, von der Du Instanzen anlegen kannst und die Du einfach testen können solltest. Die Instanz selbst ist aber natürlich in der ursprünglichen Klasse gekapselt. Oft ist dies bereits die naheliegende Lösung.
Generell sind dies aber auch Dinge, die nur passieren können, wenn man einfach so entwickelt und Tests dann später macht. Bei Test Driven Development würde man in diese Situation nie kommen meine ich.

Ist es evtl. eine Idee, rein zu Übungszwecken mal etwas TDD auszuprobieren? Kent Becks "Test Driven Development: By Example" Buch wäre da mein Tipp. (Ich kaufe ja gerne Bücher - ich habe mir da einen monatliches Etat eingeräumt, das ich dann nutze. Ich finde es nicht gut, dass man einfach so bei Google nach einem PDF eines Buches suchen kann und dann das Werk von irgend wem eingescannt findet, da die Autoren ja davon leben wollen und müssen und ich will ja immer neue, aktualisierte Bücher möchte ...)
Das ist kein Aufruf a.la. "Du musst TDD praktizieren". Es ist aber eine einfache Übung, so wie es viele Übungen gibt. Und man schreibt dann testbare Methoden. Und wenn man dann ohne Tests Code schreibt, dann hat man ein gewisses Wissen, wie diese testbaren Klassen denn aussahen und richtet sich etwas danach. Optional kann man sich auch gewisse Praktiken anschauen / identifizieren. Da habe ich aber keine passenden Links / Bücher zur Hand.

Noch einmal: Das ist meine pers. Sicht. Das ist etwas, das ich in der Praxis durchaus erlebt habe und was dort so auch gewollt ist oder akzeptiert wurde. Das muss so nicht sein. Es gibt garantiert gegensätzliche Meinungen (z.B. bei eurem Prof ) und da muss man sich immer überlegen, was man macht. Im Dunstkreis des Profs wird die Entscheidung leicht fallen, da man von ihm Punkte bekommt. In einem Projekt ist es ebenso einfach - da erfüllt man die Anforderungen so gut es geht und wenn die Anforderung ist, dass alles ein Interface und ein Controller bekommt und man alle 2 Stunden gen Grady Booch beeten muss: Was macht man nicht alles für seinen Stundenlohn....

 

[Gelöschtes Mitglied 65838]

Was wir nun noch ändern müssen, sind die Stellen, an denen Instanzen erzeugt werden. Das ist eine typische Sache: Das wenn möglich zentralisieren. DIP schlägt dazu z.B. Praktiken vor (z.B. bei clean-code-developer.de):
- Konstruktorparameter
- Inversion of Control Container
- Dependency LookupDie notwendigen Anpassungen an den Abhängigkeiten fallen also nicht wirklich wild aus.

meinst du damit FLUID und builder und factory oder wie ?

ich versteh davon gar nichts ... oder stell ich mich jetz wieder an wie der erste mensch

 

[Neumi5694]

Ok, sorry, dass ich das nicht direkt verstanden hatte. Jetzt verstehe ich Deinen Punkt.

Im Folgenden einmal eine Erläuterung meiner Sichtweise.

Hier beissen sich zwei Forderungen:
a) Dependency Inversion Principle
Dahinter versteckt sich., dass (High Level) Klassen nicht von (Low Level) Klassen abhängig sein sollten sondern von Interfaces und dass Interfaces nicht von Details abhängig sein sollten sondern Details von Interfaces.

b) Ich sehe aber auch immer YAGNI (You aint gonna need it)

Wenn man die typischen Business Applikationen erstellt mit der typischen Datenbank mit Entitities und darauf aufbaen dann ein Business Logic Layer und darauf dann irgendwelche Controller / UIs, dann finden sich immer wieder typische Fälle, wo klar ist: Hier braucht man keine Interfaces:
- Entities haben in der Regel keine Interfaces. Ich habe zumindest noch zu der Klasse Empolyee kein Employee Interface gesehen oder so. (Hier auch wichtig: Die Anforderung zu einem Interface kommt aus meiner Sicht immer von denen, die etwas nutzen wollen! Dazu später noch einmal mehr!)
- Dinge auf oberster Ebene - die werden nicht genutzt - daher auch keine Interfaces. Also der EmployeeController des Rest Service. Da habe ich noch nie ein Interface gesehen und das macht auch keinen Sinn.

Nun wie versprochen meine Sicht auf diese DIP und zu den Interfaces. Wann und wie erstelle ich diese?

Generell erstelle ich nie pauschal irgendwelche Interfaces. YAGNI! So lange ich nicht weiss, ob ich die überhaupt brauche, wird da nichts erstellt!
So schreibe ich also z.B. eine Klasse Dog. Es gibt kein DogInterface (Und wird es so eigentlich auch nie geben). Es gibt keinen Grund, das konkrete Interface, das Dog bietet, komplett auch in ein Interface zu schreiben.
Die Interfaces kommen nur über die Nutzer der Klasse:
- Eine Nutzung von Dog ist, dass er gefüttert (feed) werden kann. Jemand, der einen Hund füttern kann, will aber nicht abhängig sein von der konkreten Implementierung. Daher braucht man hier nun ein Interface. Aber was für ein Interface? Ein DogInterface? Das wohl kaum, denn es wrd ja nur das feed() benötigt. Also gibt es ein Interface Feedable oder so.
- Der Hund soll bellen (bark) können. Also bauchen wir hier auch ein entsprechendes Interface. Aber wieder speziell für diesen Sachverhalt. Die Alarmanlage, die dann den Hund bellen lässt, hat mit dem Füttern ja nichts am Hut. Und statt einem reellen Hund steckt da vermutlich meist auch eine Elektronik dahinter, die dann "bellt". Also wirklich nichts mit DogInterface oder so.
...

Natürlich kann es Fälle geben, wo Interface und Implementierung überein stimmen. Dann ist das Map Interface auch genau das, was man in der HashMap implementiert.
Und in einem Punkt hast du Recht: Es kann durchaus Sinn machen, das Beispiel von mir auf zu dröseln:
- Translator wird ein reines Interface
- Die Implementierung wird zu MapTranslator
- Du kannst dann Deine Implementierung als ArrayTranslator hinzu fügen oder so

Sowas gibt es bei formalistischen Entwicklungen durchaus. Dann werden Regeln gerne so angewendet. Da gibt es dann einen Architekten oder Prof, der einem dummen Programmierer oder Studenten sagt, wie es sein muss. Weil er es so meint und das ohne wirklichen Grund (Es ist eine einfache Formalie.)

YAGNI ist daher sehr wichtig. Nehmen wir wieder das Beispiel:
- Ich habe da jetzt diese Implementierung. Jetzt kommt - entgegen allen Erwartungen - diese neue Implementation. Ich kann es relativ einfach umstellen. Das Interface bekommen 1:1 genu das, was die Klasse hat. Es ist halt eine triviale Klasse. Die Abstraktion ist also einfach. Die Klasse selbst wurde nur umbenannt und implementiert das Interface nun. Damit sind wir aber schon fertig.

Was wir nun noch ändern müssen, sind die Stellen, an denen Instanzen erzeugt werden. Das ist eine typische Sache: Das wenn möglich zentralisieren. DIP schlägt dazu z.B. Praktiken vor (z.B. bei clean-code-developer.de):
- Konstruktorparameter
- Inversion of Control Container
- Dependency LookupDie notwendigen Anpassungen an den Abhängigkeiten fallen also nicht wirklich wild aus.

Daher ist aus meiner Sicht immer der gesunde Menschenverstand gefragt: Braucht man das, was ich da schreibe, denn überhaupt?


Dazu ist meine Meinung halt ganz klar: Code Smell. Eine private Methode zeigt, dass Deine Klasse in Verhalten hat (Methoden machen ja irgendwas und daher ist es ein Verhalten), das schlicht kein Verhalten Deiner Klasse ist (Weil das Verhalten ja eigentlich durch die von außen aufrufbare Methoden bestimmt wird).

Daher ist die Frage immer: Was für eine provate Methode hast Du da? Ist da ggf. ein Refactoring angebracht und dieses Verhalten kommt in eine eigene Klasse? Dann hast Du eine Klasse, von der Du Instanzen anlegen kannst und die Du einfach testen können solltest. Die Instanz selbst ist aber natürlich in der ursprünglichen Klasse gekapselt. Oft ist dies bereits die naheliegende Lösung.
Generell sind dies aber auch Dinge, die nur passieren können, wenn man einfach so entwickelt und Tests dann später macht. Bei Test Driven Development würde man in diese Situation nie kommen meine ich.

Ist es evtl. eine Idee, rein zu Übungszwecken mal etwas TDD auszuprobieren? Kent Becks "Test Driven Development: By Example" Buch wäre da mein Tipp. (Ich kaufe ja gerne Bücher - ich habe mir da einen monatliches Etat eingeräumt, das ich dann nutze. Ich finde es nicht gut, dass man einfach so bei Google nach einem PDF eines Buches suchen kann und dann das Werk von irgend wem eingescannt findet, da die Autoren ja davon leben wollen und müssen und ich will ja immer neue, aktualisierte Bücher möchte ...)
Das ist kein Aufruf a.la. "Du musst TDD praktizieren". Es ist aber eine einfache Übung, so wie es viele Übungen gibt. Und man schreibt dann testbare Methoden. Und wenn man dann ohne Tests Code schreibt, dann hat man ein gewisses Wissen, wie diese testbaren Klassen denn aussahen und richtet sich etwas danach. Optional kann man sich auch gewisse Praktiken anschauen / identifizieren. Da habe ich aber keine passenden Links / Bücher zur Hand.

Noch einmal: Das ist meine pers. Sicht. Das ist etwas, das ich in der Praxis durchaus erlebt habe und was dort so auch gewollt ist oder akzeptiert wurde. Das muss so nicht sein. Es gibt garantiert gegensätzliche Meinungen (z.B. bei eurem Prof ) und da muss man sich immer überlegen, was man macht. Im Dunstkreis des Profs wird die Entscheidung leicht fallen, da man von ihm Punkte bekommt. In einem Projekt ist es ebenso einfach - da erfüllt man die Anforderungen so gut es geht und wenn die Anforderung ist, dass alles ein Interface und ein Controller bekommt und man alle 2 Stunden gen Grady Booch beeten muss: Was macht man nicht alles für seinen Stundenlohn....

Eine eigene Klasse mit Public-Methoden soll es ja gerade eben NICHT geben, wenn etwas nur lokal verwendet wird und sehr spezialisiert ist. Trotzdem möchte man sicherstellen, dass es seinen Job erledigt (Stichwort Test Driven, ein Buch über JUnit als Entwicklungshilfe hab ich mir schon mal reingezogen ). Das fehlt mir bei JUnit noch. Gerade wenn es um komplexere spezialisierte Abläufe geht, von denen es von außen nur einen Zugang gibt, möchte man doch eine Möglichkeit haben, die einzelnen Komponenten zu testen, die niemanden außer diese Klasse was angehen.

Sagen wir beispielsweise mal, es geht um das Umwandeln einer Datensammlung in ein anderes Format. Von außen übergibt man die Sammlung, es kommt eine andere raus. Innen wiederum gibt es z.B. pro Element verschiedene Fälle, für die jeweils verschiedene Auswertungen gemacht werden. Das alles soll nach außen hin nicht sichtbar sein, aber einen Funktionstest der einzelnen Komponenten hätte man halt doch gerne.

Du hast ein Auto als Beispiel gebracht: Ja, dem Nutzer ist nicht bewusst, wie der Motor funktioniert, dessen Funktionen sind Private.
Aber ein Techniker muss prüfen können, ob Sensoren richtig ausgewertet werden, er hat auch passende Werkzeuge dazu. Die Sensoren selbst sind natürlich eine eigene "Klasse", aber die Auswertung findet im Bordcomputer statt und die lässt sich ebenfalls prüfen, auch wenn der User dazu keinen Zugang hat oder sie nie direkt sieht.

Ich setz natürlich auf verschiedene Tests. Für grobe "klappt alles?" Tests verwende ich außerdem output Tests. Die Software wird mit verschiedenen Einstellungen oder Projekten gefüttert, erzeugt Output-Dateien. Vorher wurden anhand der selben Einstellungen schon Dateien erzeugt, manuell geprüft und für "gut" befunden. Änderungen an der Ausgabe werden als Fehler erkannt und müssen neu überprüft werden. Am Ende ist es für komplexe Operationen das, was man mit JUnit im Detail macht. Manchmal wäre es halt angenehm, noch detaillierter testen zu können, ohne gleich alles auf public oder package protected setzen zu müssen



edit: Mir fällt gerade auf, wie weit wir vom ursprünglichen Thema abgekommen sind

 

[KonradN]

edit: Mir fällt gerade auf, wie weit wir vom ursprünglichen Thema abgekommen sind

Ja, hatte daher auch mal den report Knopf gedrückt, aber das scheint noch ok zu sein - wir sind nicht nicht im eigenen Thread gelandet ....

@Neumi5694 Ich habe gerade Probleme, Dein Problem zu verstehen. Wo ist das Problem, dass da eine neue Klasse hinzu kommt, die ggf. package private ist? (Wobei ich da eigebtlich immer nur public Klassen habe). Aber das ist ggf. auch nicht so wichtig - meine Sichtweise habe ich versucht darzulegen und da müssen wir ja auch nicht auf einen Nenner kommen. Der Weg muss nicht passen und nur weil ich damit recht gut fahre heisst es in keiner Weise, dass der Weg für euch sinnvoll ist.

@Joreyk Da geht es schon sehr weit in eine bestimmte Richtung - viele Frameworks bieten eine Dependency Injection Möglichkeit was dann ein Inversion of Control ermöglicht. Da gibt es aber auch viele "Zwischenschritte", die denbar sind.

Ich weiss jetzt gerade nicht, welche Quelle gut sein könnte, um sich damit tiefer zu beschäftigen. Bezüglich Clean Code rate ich am Anfang immer zu clean-code-developer.de, weil es da Stufenweise aufgebaut wird. Aber da wird das auch nicht groß tiefer erläutert meine ich. Evtl. kann es interessant sein, mehr zu Dependency Injection zu lesen. Bei spring Boot gibt es manchmal auch etwas mehr dazu (Ich hatte da mal ein Buch, das da ein ganzes Kapitel zu hatte). Aber es gibt auch reine DI Frameworks wie Guice von Google. Da findet sich evtl. auch Dokumentation, die die Grundlagen erläutert.

Ich habe heute einen Tag der komplett voll ist mit Meetings, daher werde ich vermutlich nicht dazu kommen, da noch etwas mehr heraus zu suchen. Aber ich bin zuversichtlich, dass Du da auch noch etwas mehr zu finden wirst (So Du den Punkt vertiefen möchtest).

 

[Gelöschtes Mitglied 65838]

das dependency injection zeug hab ich mir schon mal angeschaut aber einen sinn dahinter hab ich noch nicht dahinter entdeckt

hatte das beispiel mit printer
dass man irgend was was printen kann übergibt und die klasse dann immer noch funktioniert egal was für einen printer man übergibt

ob das das ding ist mit injection keine ahnung..ich verstehs nicht und weis auch nicht wann ich das benutzen soll

 

[berndoa]

tut es auch.. es gibt immer 10 wege
du warst ja auch nah dran... du hast ja nur ein =false; vergessen

es hat ja niemand gesagt "dein code ist müll", ich wollte dir nur zeigen wie man es auch noch machen kann

nur du musst lernen den für den ersten blick besten zu gehen, du wirst niemals immer den besten gehen, das tut kein programmierer
bei den "basics" solltest du aber immer den richtigen gehen

zb:
ja man kann es mit 2 lokalen variablen lösen => durchs umstellen kann man es ohne 2 lokalen variablen lösen
damit ist der code lesbarer ... stell dir vor du machst mal was komplexeres.. dann hast irgendwann 10 lokale variablen und schon puff.. kennt sich niemand mehr aus => blöd

deswegen gleich kleine tricks lernen um gleich mehr zu lernen


es gibt noch paar andere sachen was ich dazu sagen könnte aber ...

Ach, anderswo heißt es "Einfach irendeinen unleserlichen Müll hinrotzen, ist eine Frechheit" weil eine Variable groß statt klein geschrieben wurde und damit Konvention numer 4375 nicht eingehalten wurde.
Und man daher angelbich nix bis gar nix mehr versteht.

Ach, Scheinheiligkeit ist doch eine Tugend

PS:
Der Threadersteller schreibt doch ersthaft eine Variable so "carryOn".
Mitten im Wort ein Großbuchstabe!
Verbietet sowas nicht irgendeine Konvention, wo bleibt da der Aufschrei der Menschheit? :O

Ich spüre schon das Universum um mich zusammenstürzen wegen dieses Konventionsbruchs!

 

[berndoa]

Hallo ist es mögliche eine Variable in einer Schleife zu initialisieren?
Die "helpFunction.openScannerString()" öffnet einen Scanner der den Wert zurück gibt.
Hier meine Problem:
[CODE lang="java" title="Methode"]public static boolean yesOrNot() {

boolean carryOn = true;
boolean bool;

while(carryOn) {
switch(helpFunction.openScannerString()) {
case "j":
case "ja":
case "yes":
bool = true;
carryOn = false;
break;
case "nein":
case "n":
case "no":
bool = false;
carryOn = false;
break;
default:
System.err.println("Bitte geben Sie Ja oder Nein ein.");

}
}
return bool;
}[/CODE]

M

Hallo ist es mögliche eine Variable in einer Schleife zu initialisieren?
Die "helpFunction.openScannerString()" öffnet einen Scanner der den Wert zurück gibt.
Hier meine Problem:
[CODE lang="java" title="Methode"]public static boolean yesOrNot() {

boolean carryOn = true;
boolean bool;

while(carryOn) {
switch(helpFunction.openScannerString()) {
case "j":
case "ja":
case "yes":
bool = true;
carryOn = false;
break;
case "nein":
case "n":
case "no":
bool = false;
carryOn = false;
break;
default:
System.err.println("Bitte geben Sie Ja oder Nein ein.");

}
}
return bool;
}[/CODE]

Mal meinen "Griff ins Klo", wie es uuu3uuu so schön ausdrückt, zum Thema abgeben:

Du könntest auch hingehen, innerhalb der Methode statt mit 2 Bools stattdessen mit einer int Variable arbeiten, die die Werte -1,0,1 annehmen kann.

Heißt du initialisierst eingangs mit 0:

int griffinsklo=0;

und bei den 2 relevanten Fällen im Switch Gebilde schreibst du eben

[CODE lang="java" title="int griffinsklo=0;"]griffinsklo=1;//im "ja" Fall

bzw.

griffinsklo=-1; //im "nein" Fall

[/CODE]

heißt ein Wert von 0 bedeutet "wurde initialisiert aber noch nicht neu belegt",
Wert 1 heißt " ja Fall ist eingetreten" und
Wert -1 heißt "nein Fall ist eingetreten".

Entsprechend muss er Kopf der while Schleife eben lauten

while(griffinsklo==0){
....
}

Natürlich musst du dann mittels ternärem operator if-else if-else Konstruk oder Ähnlichem noch eine bool variable bauen die abhängig vom Wert von griffinsklo ebenb true oder false ist. Und die dann returnen

 

[Gelöschtes Mitglied 65838]

Der Threadersteller schreibt doch ersthaft eine Variable so "carryOn".

das ist das camelCase das für Klassen felder und methoden der Konvention entspricht

 

[Neumi5694]

Der Threadersteller schreibt doch ersthaft eine Variable so "carryOn".
Mitten im Wort ein Großbuchstabe!
Verbietet sowas nicht irgendeine Konvention, wo bleibt da der Aufschrei der Menschheit? :O

Nein, lower camel case ist hier genau die richtige Vorgangsweise.
Das Problem wurde mittlerweile auch ausgiebig besprochen und auf mehrere Arten gelöst. Der -1/0/1 Ansatz hat dabei den größten Retro-Aspekt, Gratulation. So hätt ich's 1987 auch gemacht.

 

[Gelöschtes Mitglied 65838]

M

Mal meinen "Griff ins Klo", wie es uuu3uuu so schön ausdrückt, zum Thema abgeben:

Du könntest auch hingehen, innerhalb der Methode statt mit 2 Bools stattdessen mit einer int Variable arbeiten, die die Werte -1,0,1 annehmen kann.

Heißt du initialisierst eingangs mit 0:

int griffinsklo=0;

und bei den 2 relevanten Fällen im Switch Gebilde schreibst du eben

[CODE lang="java" title="int griffinsklo=0;"]griffinsklo=1;//im "ja" Fall

bzw.

griffinsklo=-1; //im "nein" Fall

[/CODE]

heißt ein Wert von 0 bedeutet "wurde initialisiert aber noch nicht neu belegt",
Wert 1 heißt " ja Fall ist eingetreten" und
Wert -1 heißt "nein Fall ist eingetreten".

Entsprechend muss er Kopf der while Schleife eben lauten

while(griffinsklo==0){
....
}

Natürlich musst du dann mittels ternärem operator if-else if-else Konstruk oder Ähnlichem noch eine bool variable bauen die abhängig vom Wert von griffinsklo ebenb true oder false ist. Und die dann returnen

wenn man diesen weg gehen würde, würde ich die "magic numbers" versuchen zu verhindern dh konstanten davor einzutragen als wirkliche konstante felder

wie zb

final int ABSOLUTER_GRIFF_INS_KLO = 1;
final int NOCH_KEIN_GRIFF_INS_KLO = 0;
final int KEIN_GRIFF_INS_KLO = -1;

 

[KonradN]

Ach, anderswo heißt es "Einfach irendeinen unleserlichen Müll hinrotzen, ist eine Frechheit" weil eine Variable groß statt klein geschrieben wurde und damit Konvention numer 4375 nicht eingehalten wurde.

Wie lange wird diese Trotzphase noch anhalten? Hast Du vor, da noch länger dran festzuhalten?

Ansonsten könnte man jetzt noch den Unterschied zwischen einem Fragesteller und jemandem, der aktiv helfen will heraus arbeiten. Man könnte auch schauen, was denn alles bemängelt wurde - da war die Variable nur ein kleiner Punkt. Aber das wäre vermutlich Zeitverschwendung - da dies nichts zu dem Thread bei trägt, ist dies viel mehr eine Sache für die Moderatoren ...

 

[Gelöschtes Mitglied 65838]

helpFunction.openScannerString())

weils mir grad so einfällt... java hat im klassen kontext nur "methoden" ... keine funktionen, ob man statische methoden als funktionen bezeichnen kann weiss ich nicht

da du aber help mit kleinen buchstaben beginntt geh ich davon aus dass es keine klasse ist sondern irgend ein objekt, dh es ist nicht statisch und somit eine helpMethod ... gehe zumindest davon aus

für was konventionen nicht alles gut sind

 

[berndoa]

Wie lange wird diese Trotzphase noch anhalten? Hast Du vor, da noch länger dran festzuhalten?

Ansonsten könnte man jetzt noch den Unterschied zwischen einem Fragesteller und jemandem, der aktiv helfen will heraus arbeiten. Man könnte auch schauen, was denn alles bemängelt wurde - da war die Variable nur ein kleiner Punkt. Aber das wäre vermutlich Zeitverschwendung - da dies nichts zu dem Thread bei trägt, ist dies viel mehr eine Sache für die Moderatoren ...

Wieso Trotzphase?
Das ist die "Da will man Jemandem helfen und ein anderer Trottel pisst sich von der Seite wegen einer großgeschriebenen variable ein. Als gäbs nichts Wichtigeres im Leben, im dortigen Thread und im stark fehlerhaften Code des Threaderstellers. Dann gibts halt Krieg wers so haben will" Phase

Stimmt ja, Oneixee5 hatte sich ja auch in einer Aufgabe, in der es nur ja und nein als Eingabe geben soll, dran gestört, dass mein Vergleich nciht alle denkbaren Shcwachsinnseingaben gleich auch noch mit abcheckt...Stimmt ja...

Soll ich dir eigentlich neues Popcorn besorgen? Das Alte ist doch bestimmt schon kalt und schmeckt nicht mehr. Und wir wollen doch nicht dass dir noch schlecht wird von altem Essen
Aber achte auf deine Linie, Popcorn hat auch gut Kalorien


Mal einer ernste Frage dazwischen:
Wie willst du mit einer boolean variable, die bekanntlich nur die 2 zustände "true" und "false" annehmen kann, 3 Zustände darstellen?

Also ohne jetzr irgendwelchen Sonderkram zu nutzen den so gut wie Niemand , zumindest kein Anfänger, kennt?
Oder doch 2 Variabeln?

oder gar den "noch nicht initialiert" Status weglassen? Aber das verstößt doch sicher gegen jegliches Konventionsempfinden gewisser Zeitgenossen wenn man die Variable bspw. mit fals vorbelegt, oder?
kann ja allerlei schlechte Folgen haben, wie bspw. zu Beginn ungewollt die while Bedingung erfüllen

 

[Gelöschtes Mitglied 65838]

Wie willst du mit einer boolean variable, die bekanntlich nur die 2 zustände "true" und "false" annehmen kann, 3 Zustände darstellen?

die 3 Zustände kann man mit einem Optional erreichen
weil ein optional true false oder empty sein kann

dass man einen Anfänger erstmal ein Optional reindrückt der gerade mit arrays und schleifen und strings kämpft halte ich aber genauso schwachsinnig wie du... das optional gehört ja doch schon zu dem Sonderkram

eher zumuten würde ich ein enum dann mit zb

enum Typ{
    Ja,Nein
}

weil ein enum wert auch null sein kann dh hier hat man "aussage kräftige" worte wie zb

if(Typ.Ja = xyzMethode())

booleans werden ja doch schnell mal unübersichtlich

oder wie ich es ohne variablen gemacht hab


ob man das jetzt in ein array ... einer map ( die ich selber noch nie hergenommen hab ) ... einer liste oder sonst was speichert is ja erstmal sack egal wenn man mit einem Switch case kämpft

 

[KonradN]

Das ist die "Da will man Jemandem helfen und ein anderer Trottel pisst sich von der Seite wegen einer großgeschriebenen variable ein. Als gäbs nichts Wichtigeres im Leben, im dortigen Thread und im stark fehlerhaften Code des Threaderstellers. Dann gibts halt Krieg wers so haben will" Phase

Stimmt ja, Oneixee5 hatte sich ja auch in einer Aufgabe, in der es nur ja und nein als Eingabe geben soll, dran gestört, dass mein Vergleich nciht alle denkbaren Shcwachsinnseingaben gleich auch noch mit abcheckt...Stimmt ja...

Nur um einmal klar zu stellen, was Dich so massiv stört und worüber Du Dich hier so aufregst:

In Java werden Variablen klein geschrieben: "Eingabevariable" ist also kein valider Variablenname. Statt equals sollte man den Text mit equalsIgnoreCase vergleichen oder die Eingabe vorher explizit in Kleinbuchstaben umwandeln. Andernfalls müsste man jede Variante mit equals vergleichen.
Solche Vergleiche sind auch schlecht: int vergleichsjahr=(Eingabevariable.equals("ja"))?2022:2021; Bei einer Falscheingabe wird einfach mit einem Wert weitergearbeitet, welcher mit der Eingabe eigentlich nichts zu tun hat. Die festen eingetragenen Jahreszahlen bedeuten dann auch, dass die Software nur diese Jahr funktioniert.
Im original Post steht:
System.out.println("Hatten sie dieses Jahr schon Geburtstag? Antworten sie mit ja oder nein.");
So muss man auch prüfen ob ja/nein/oder etwas anderes eingegeben wurde. Es steht da nämlich nicht: antworten sie mit ja oder irgendetwas anderem.
Nochwas, eine Variable "faktor" (Faktor: Zahl oder Größe, mit der eine andere multipliziert wird) zu nennen und dann eine Addition oder Subtraktion damit durchzuführen, ist naja ...

Das sind die zwei Punkte und die sind sachlich vorgetragen worden. Der erste Punkt, den Du selbst immer ständig bringst, ist ein einfacher kleiner Satz. Was kann einen an so einem einfachen Hinweis so stören?

Und auch die weiteren Punkte sind ganz normale Hinweise. Und wenn Du den original Code angeschaut hättest: Das Problem bestand nun einmal genau darin, dass der TE eben alle möglichen Schwachsinneingaben auch abfangen wollte.

Wenn man dann noch schreibt: "Aber das ist vermutlich nur mein persönlicher, schlechter Programmierstil, also besser nicht als Vorbild nehmen." - dann frage ich mich nach dem Sinn der Antwort! Du schreibst bewusst eine schlechte Antwort um am Ende mitzuteilen, dass die Antwort schlecht ist! Was?

Da das obere normale Hinweise waren, muss es also schlicht an diesem letzten Satz gelegen haben. Deshalb bist Du irgendwie ausgetickt, so dass Du so massiv auf einfachen Dingen herum reiten must, bei denen man eigentlich meinen müsste, dass da Diskussionen nicht möglich sind!
Und der Hinweis war durchaus berechtigt - da waren doch schon hilfreiche Antworten - wieso musst Du so etwas bringen? Du hast zu der bisherigen Hilfe nicht wirklich etwas beigetragen und es war ein Schritt zurück (Meiner Meinung nach).

Ich gratuliere Dir - du hast es da also wirklich auf eine Stufe mit unserem Tobias und JW geschafft. Das ist eine super Leistung! Dieses Niveau haben bisher nur 3 Leute erreicht! Darauf kann man sich also richtig was einbilden!

 

[Neumi5694]

Lassen wir's mal gut sein und ihn das letzte Wort haben. Ich bin sicher, unsere Egos verkraften das.
Das Problem ist längst gelöst und die konstruktiven Beiträge weiter oben zu finden.