guter Stil void oder boolean

[Luis Bischof]

Guten Tag,
seit längerem stelle ich mir die Frage, was ist ein guter Stil bei Java, wenn man eine grobe Vorstellung über eine Methode hat, aber sich noch nicht sicher sein kann ob ein spezieller Datentyp zurückgegeben werden soll.

Frage an euch. Welcher Stil ist besser?

1.
public void neueMethode(){
andereMethode();
}

oder

2.
public boolean neueMethode(){
return andereMethode();
}

[Michael Paap]

Ich sehe nicht, inwiefern das eine *Stilfrage* sein sollte.

Wenn es eine Methode ist, die dir eine ja/nein-Frage beantwortet, gibst
du ein boolean zurück, wenn es eine Methode ist, die lediglich etwas
tut, aber dir keine explizite oder implizite Frage beantwortet, nimmst
du void. Wenn es eine Methode ist, die lediglich etwas tun soll, was
aber evtl. nicht klappt, dann codierst du das durch eine Exception,
nicht durch einen boolean-Rückgabewert. Ich sehe da eher wenige
Überschneidungen.

Beschreibe am besten mal einen etwas konkreteren Fall, in dem sich dir
deine Frage aufdrängt.

Gruß
Michael Paap

[Michael Paap]

Am 09.07.2022 um 23:48 schrieb Stefan Ram:
> Luis Bischof <luisb...@gmx.de> writes:
>> seit l=C3=A4ngerem stelle ich mir die Frage, was ist ein guter Stil bei Jav=
>> a, wenn man eine grobe Vorstellung =C3=BCber eine Methode hat, aber sich no=
>> ch nicht sicher sein kann ob ein spezieller Datentyp zur=C3=BCckgegeben we=
>> rden soll.
>
> Wenn der Typ noch nicht klar ist, dann gibt es ja keinen
> Grund, gerade den speziellen Typ "bool" dafür festzulegen.
>
> Dabei ist eine Bedeutung des englischen Adjektivs "void"
> laut einem allgemeinen Englisch-Wörterbuch: "Not occupied;
> unfilled", das Substantiv "void" bedeutet auch: "An open
> space; a gap. - das wäre ja genau die richtige Bedeutung!

Sorry, aber das halte ich für arg dubiose Theoriefindung. :-)

Eine Methodendeklaration, die als "Rückgabetyp" void deklariert, will
damit *nicht* aussagen, dass man noch nicht weiß, was man zurückgeben
wird, sondern sie sagt ganz klar aus: Es wird *nichts* zurückgegeben.
Das Wort "void" ist hier im Sinne von "Leere" oder "Nichts" zu verstehen.

Irgendwelche sonstigen allgemeinsprachlichen Bedeutungen des Wortes
"void" sind für den Sachverhalt, den "void" als Rückgabetyp einer
Methodendeklarations beschreibt, genauso falsch, wie es die Aussage
wäre, dass die Methode Apfelkuchen zurückgeben kann wäre, wenn "void"
zufällig auch noch *diese* weitere Bedeutung hätte.

Gruß
Michael

[Patrick Roemer]

Responding to Luis Bischof:

> seit längerem stelle ich mir die Frage, was ist ein guter Stil bei Java, wenn
> man eine grobe Vorstellung über eine Methode hat, aber sich noch nicht sicher
> sein kann ob ein spezieller Datentyp zurückgegeben werden soll.

Wenn Du nicht sicher bist, ob und was die Methode zurückgibt, kannst Du
sie noch nicht schreiben. :) Die Signatur ist eigentlich das erste, über
das man sich im Klaren sein sollte. Es kann natürlich mal vorkommen,
dass man bewußt erst mal nur eine Annäherung implementiert, um ein
Gefühl dafür zu bekommen, was man wirklich braucht, aber da bin ich (wie
ansonsten auch) bei Michael: Das ist dann keine Stilfrage und vom
konkreten Fall abhängig.

[Patrick Roemer]

Responding to Stefan Ram:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>Dabei ist eine Bedeutung des englischen Adjektivs "void"
>>laut einem allgemeinen Englisch-Wörterbuch: "Not occupied;
>>unfilled", das Substantiv "void" bedeutet auch: "An open
>>space; a gap. - das wäre ja genau die richtige Bedeutung!

>>Also eher "void".
>
> Dazu paßt auch, daß »void« kein Typ ist, sondern ein
> Schlüsselwort, das eine Alternative zur Angabe eines
> Typs darstellt:
>
> |Result:
> | UnannType
> | void
> JLS 8.4.5

Dass "void" in Java nur ein Pseudotyp ist (eine void-Methode gibt _gar
nichts_ zurück, hat also keinen Rückgabetyp), ist eine von C geerbte
Eigenheit. In anderen Sprachen wird dasselbe Konzept z.B. durch einen
echten Typ "Unit" ausgedrückt, der genau einen Wert "()" besitzt - und
damit natürlich genau gar keine Bedeutung trägt.

Ich finde es recht erstaunlich, dass die JLS keine tragfähige Definition
für "void" beinhaltet (vielleicht habe ich heute auch nur ganz
schlechtes Suchkarma), aber ich bin mir sehr sicher, dass die Semantik
"diese Methode hat nur Nebeneffekte" ist, und nicht "diese Methode weiss
noch nicht so recht, was sie zurückgeben will".

Eine etwas bessere (aber längst nicht passende) Annäherung an diese
Bedeutung wäre der Typ "Nothing" in Scala, der keinen Wert beinhaltet,
der aber ein Subtyp jedes anderen Typs ist. Im Zusammenspiel mit
Inferenz für Methodenrückgabetypen könnte man da eine Methode so
"evolvieren":

// inferred return type: Nothing
def foo(i: Int) =
??? // throws NotImplemented, type: Nothing

// inferred return type: Int
def foo(i: Int) =
if(i >= 0)
then i
else ???

// inferred return type: Int
def foo(i: Int) =
if(i >= 0)
then i
else -i

// Fertig!
def foo(i: Int): Int =
if(i >= 0)
then i
else -i

...aber empfehlen würde ich dieses Vorgehen sicher nicht - erst denken,
dann tippen.

[Patrick Roemer]

Responding to Stefan Ram:

> Patrick Roemer <sang...@netcologne.de> writes:
>>Wenn Du nicht sicher bist, ob und was die Methode zurückgibt, kannst Du
>>sie noch nicht schreiben. :)
>

> Wenn das ironisch gemeint sein sollte (wegen des Smileys),
> frage ich mich, was dann Deine wirkliche Meinung dazu ist.

Das ist grundsätzlich so meine Meinung - der Smiley soll nur
signalisieren, dass derart pauschale Aussagen immer falsch sind! :)

> Jedenfalls gibt es Ansätze, wie "Code As Design" (Jack Reeves, 2005),
> die für den Entwurf Code vorsehen. Vergleiche auch "stepwise
> refinement" wie in Elan.
>
> Beim Entwurf kann es die mentale Belastung reduzieren, wenn
> man nicht gleich alle Details hinschreiben muß.

Sicher. Aber die Details wären für mich die Implementierung, die Typen
und Signaturen das Design.

> In Python kann ich schreiben:
>
> # a stub
> def ask_operator():
> pass

Man verwendet ja eine statisch getypte Sprache, damit man sowas nicht
machen kann - ohne wirklich

void askOperator() {
// perhaps some side-effecting code here
}

zu meinen.

Interessanter würde es noch hiermit:

def ask_operator(x):
pass

> PS: Eine "saubere" Lösung wäre an sich die Definition eines
> speziellen Typs als Rückgabetyp für Funktionen deren
> Rückgabespezifiktion noch offen ist, aber ich finde, solch
> ein Typ, wie "ToBeSpecified", würde beim Entwurf schon
> wieder zu sehr ablenken.

Warum ein generisches ToBeSpecified und nicht ein spezifischer
Platzhaltertyp, der schon mal so viel Semantik trägt, wie man im Moment
zusammenbringt (zumindest hat er schon mal einen sprechenden Namen und
kann nicht mit anderen Typen velwechsert werden), und den man iterativ
zum "real thing" verfeinern kann?

interface AskResult {}

interface AskService {
AskResult askOperator();
}

...und bei Bedarf noch:

class PlainAskService implements AskService {
AskResult askOperator() { throw new NotImplemented(); }
}

[Michael Paap]

Am 11.07.2022 um 16:25 schrieb Patrick Roemer:

> Sicher. Aber die Details wären für mich die Implementierung, die Typen
> und Signaturen das Design.

Das. Zumal man ja eine Methode, die etwas liefern soll, nicht in die
Welt setzt, weil man grad nichts zu tun hat, sondern, weil man das, was
sie liefern soll, benötigt.

Ich stelle mir gerade vor, ein Teamkollege teilt mir mit, er würde gerne
in dem Kram, den vorwiegend ich betreue, eine Methode haben, weil er die
aus "seinem" Kram aufrufen muss, und die soll etwas liefern, aber er
weiß noch nicht, was. ;-)

Fällt sowas noch unter "Agil" oder gibts dafür schon ein neues Wort? ;-)

Gruß
Michael

[Patrick Roemer]

Responding to Stefan Ram:
> Patrick Roemer <sang...@netcologne.de> writes:

>>Dass "void" in Java nur ein Pseudotyp ist (eine void-Methode gibt _gar
>>nichts_ zurück, hat also keinen Rückgabetyp), ist eine von C geerbte
>>Eigenheit.
>

> In C (und C++) /ist/ "void" ein Typ:
>
> |The void type comprises an empty set of values;
> |it is an incomplete object type that cannot be completed.
> n2310, 6.2.5p19

I stand corrected. Hätte ich trotz meiner kaum vorhandenen C-Kenntnisse
wissen müssen (es gibt schließlich void-casts) oder wenigstens noch mal
nachlesen können. :/

> Die JLS 18 enthält in 8.4.5 alles, was man wissen muß:
>
> |uses the keyword void to indicate that the method does not
> |return a value
> JLS 18, 8.4.5.

Für die Implikationen, die es hat, wenn nicht jede Methode einen
Rückgabetyp hat, finde ich das schon sehr lakonisch.

>> aber ich bin mir sehr sicher, dass die Semantik
>>"diese Methode hat nur Nebeneffekte" ist, und nicht "diese Methode weiss
>>noch nicht so recht, was sie zurückgeben will".
>

> Du hast recht, was die JLS angeht. Aber hier geht es darum,
> daß jemand für seine persönliche Entwurfssprache die Bedeutung
> von "void" etwas erweitern will.

Das geht für mich (und wohl auch Michael) aus der OP-Frage nicht so klar
hervor. Aber wenn es das tatsächlich sein sollte: Meiner Meinung nach
äußerst schlechter Stil, egal, ob void oder boolean.

>>...aber empfehlen würde ich dieses Vorgehen sicher nicht - erst denken,
>>dann tippen.
>

> Woher soll ich wissen, was ich denke, bevor ich lese, was
> ich getippt habe? :)

Warum sollte sich das, was Du getippt hast, dann sinnentnehmend lesen
lassen? :)

[Patrick Roemer]

Responding to Stefan Ram:
> Patrick Roemer <sang...@netcologne.de> writes:
>>Warum ein generisches ToBeSpecified und nicht ein spezifischer
>>Platzhaltertyp, der schon mal so viel Semantik trägt, wie man im Moment
>>zusammenbringt (zumindest hat er schon mal einen sprechenden Namen und
>>kann nicht mit anderen Typen velwechsert werden), und den man iterativ
>>zum "real thing" verfeinern kann?
>

> Das wäre vom Endergebnis her sicher sinnvoll, aber es kann
> von der Vorgehensweise beim Erstellen des Entwurfs her sein,
> daß man seine Aufmerksamkeit gerade auf etwas anderes
> richten will und dann erst später dazu kommt, über diesen
> Platzhaltertyp nachzudenken, etwa seinen Namen festzulegen.

Wie Michael schrieb: Abhängigkeiten. Wenn ich eine Methode brauche,
dann, weil ich sie aufrufen will, oder weil ich zumindest darüber
nachdenken will, wie und in welchem Kontext ich sie aufrufe. Wenn ich
noch nicht einmal weiß, welche Parameter- und Rückgabetypen sie haben
sollte, gehört meine Aufmerksamkeit entweder gerade genau dahin, oder
ich habe die falschen Prioritäten.

Das mag mancher in dynamisch getypten Sprachen vielleicht etwas anders
sehen - bei meinen sehr seltenen Ausflügen in Ruby oder JS würde ich
aber tatsächlich auch genau darüber nachdenken und versuchen, die
Ergebnisse dieser Überlegungen in Methoden- und Parameternamen (oder
notfalls Kommentaren) zu fixieren. Und, wie gesagt, wenn ich eine
statisch getypte Sprache verwende, dann, weil ich gezwungen werden
_will_, darüber nachzudenken, und weil das wichtig(st)er Teil des
Designprozesses ist.

[Patrick Roemer]

Responding to Stefan Ram:
> Patrick Roemer <sang...@netcologne.de> writes:

>>Responding to Stefan Ram:

>>>Woher soll ich wissen, was ich denke, bevor ich lese, was
>>>ich getippt habe? :)
>>Warum sollte sich das, was Du getippt hast, dann sinnentnehmend lesen
>>lassen? :)
>

> |Wenn du etwas wissen willst und es durch Meditation nicht
> |finden kannst, so rate ich dir, mein lieber, sinnreicher
> |Freund, mit dem nächsten Bekannten, der dir aufstößt, darüber
> |zu sprechen
> "Über die allmähliche Verfertigung der Gedanken beim Reden" -
> Heinrich von Kleist (1805)

Dabei hilft es aber sicher auch, wenn das Vokabular mehr als nur Verben
umfasst.

[Wanja Gayk]

In article <taciqh$g7o$1...@news-cypress.fernuni-hagen.de>,
feu...@mpaap.de says...

> Ich sehe nicht, inwiefern das eine *Stilfrage* sein sollte.
>
> Wenn es eine Methode ist, die dir eine ja/nein-Frage beantwortet, gibst
> du ein boolean zurück, wenn es eine Methode ist, die lediglich etwas
> tut, aber dir keine explizite oder implizite Frage beantwortet, nimmst
> du void. Wenn es eine Methode ist, die lediglich etwas tun soll, was
> aber evtl. nicht klappt, dann codierst du das durch eine Exception,
> nicht durch einen boolean-Rückgabewert. Ich sehe da eher wenige
> Überschneidungen.

Eine Überschneidung ist etwas wie ein datennstruktur#remove, wo man z.B.
ein boolean oderr Objekt zurück geben kann, je nach dem, ob oder was
tatsächlich was entfermt wurde, oder ob das Objektz oder der Schlüssel
gar nicht vorhanden war.
Eine Exception wäre für sowas eine gewaltig überdimensionierte Kanone.

IMHO sollte eine Exception eine tatsächliche Ausnahme sein, kein Teil
des regulären Kontrollflusses.

Wenn ich zum Beispiel ein Teil vom Lager nehme, kann ich das so lösen:
a) Ich nehme es vom Lager (reduziere den Beatand um 1), war nichts drin,
fliegt eine Exception.
b) Ich nehme es vom Lager (reduziere den Beatand um 1), war nichts drin,
bekomme ich einen Identifier als Optional.
d) Ich nehme es vom Lager (reduziere den Beatand um 1), war nichts drin,
bekomme ich ein false zurück.
e) Ich nehme es vom Lager (reduziere den Beatand um 1), war nichts drin,
mache ich nichts.

Für mich ist a) okay, wenn ich immer vorher frage, ob das Teil am Lager
ist, dann fängt die Exception praktisch eine mögliche race-condition.

Wenn ich aber bei a) stumpf ohne vorher zu fragen immer vom Lager nehme
und mit dem Fall, dass es nicht am Lager ist, immer im Exceptionhandler
deale, dann missbrauche ich die Exception für den regulären
Kontrollfluss und das finde ich ein wenig unelegant.

Für mich ist e) wie ein Schuss ins Dunkle, ich gebe das Kommando den
Lagerbestand zu reduzieren und weiß am Ende nicht, ob es geklappt hat,
müsste also den Lagerbestand immer vorher nud nachher erfragen und eine
eventuelle Race-Condition könnte für einen aissehen, wie ein Erfolg und
für den anderen, wie ein Miserfolg.

Gruß,
-Wanja-


--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]