OOP: Rückgabewerte?

[Klaus G. (Gast)]

Morgen,

ich habe eine Klasse geschrieben (C++). Diese ist im Prinzip ein 
Container für spezielle Objekte, mit bisl Zucker für Zugriff, Verwaltung 
der Daten, löschen und hinzufügen...
Die Klasse besitzt einen internen Zustand.
Abhängig von diesem kann es sein, dass momentan keine neuen Einträge 
hinzugefügt werden können, oder nur bestimmte Einträge erlaubt sind.

So, was passiert wenn ein Zugriff aus Objekt schiefgeht, weil das Objekt 
momentan nicht im richtigen Zustand ist?

In "plain C" würde ich wohl über den Rückgabewert abfragen, ob eine 
Aktion erfolgreich war.
Ich hab nicht so die OOP Erfahrung, aber mir kommt es seltsam vor eine 
Methode einen Erfolgsstatus rückgeben zu lassen. Außerdem, diese Lösung 
würde beinhalten dass der Caller, nachdem er den Rückgabewert geprüft 
hat, sich um Fehlerbehandlung kümmern muss. Sollte soetwas nicht zur 
Logik der Klasse gehören und dem Caller egal sein können?
Wie würdet ihr das Lösen?

[Oliver S. (oliverso)]

Ob deine Klasse wissen kann, was ein Caller im Falle des 
Spezial-Zustandes machen soll, kannst nur du wissen.

Vergleichbares findet man ja häufig, z.B. bei den Stream-Klassen. Über 
ein Dateiende hinauslesen geht z.B. nicht. Da ist es dann auch dem 
Caller überlassen, auf so etwas zu reagieren.

Oliver

[Läubi .. (laeubi)]

Klaus G. schrieb:
> So, was passiert wenn ein Zugriff aus Objekt schiefgeht,
> weil das Objekt momentan nicht im richtigen Zustand ist?

Für so etwas gibt es (nicht nur in OOP...) Exceptions. Kommt man von der 
"error-code" Schiene mag das zunächst unhandlich erscheinen, löst aber 
diverse Probleme und führt zu einer einfacheren und flexibleren 
Programmstruktur.

[Karl H. (kbuchegg)]

Klaus G. schrieb:

> Ich hab nicht so die OOP Erfahrung, aber mir kommt es seltsam vor eine
> Methode einen Erfolgsstatus rückgeben zu lassen. Außerdem, diese Lösung
> würde beinhalten dass der Caller, nachdem er den Rückgabewert geprüft
> hat, sich um Fehlerbehandlung kümmern muss.

Sowas soll vorkommen

> Sollte soetwas nicht zur
> Logik der Klasse gehören und dem Caller egal sein können?

OOP lehnt sich oft sehr stark an die reale Welt an.

Angenommen du gehst in deiner Firma zur Werkzeugausgeb (=Objekt) und 
beauftragst den dort zuständig Mitarbeiter damit, dir eine Hilti zu 
besorgen.
Der verschwindet und in typisch objektorientierter Manier interessiert 
es dich nicht die Bohne, wie und wo der seine Hiltis in seinem Lager 
hat. Das ist sein Bier.
Jetzt ist aber keine Hilti mehr auf Lager.
Was soll geschehen? Bleibst du so lange vor dem Tresen stehen, bis die 
Werkzeugausgabe eine neue Hilti bestellt hat und die auch geliefert 
wurde; bleibst du stehen, bis ein anderer Mitarbeiter die ausgehändigte 
Hilti zurück gibt; reicht es dir, dass der Lagerverwalter sagt "Hab ich 
nicht" und du beschliesst ein anderes mal wieder zu kommen?

Das alles sind Möglichkeiten, wie man mit der Situation 'du verlangst 
etwas von einem Objekt, was zur Zeit einfach nicht möglich ist' 
handhaben kann. Und wahrscheinlich hab ich noch 5 mögliche andere 
Behandlungswege übersehen.

> Wie würdet ihr das Lösen?

Das kommt auf das Gesamtprojekt an.
Wenn ich bei Quelle etwas bestelle, was zur Zeit nicht am Lager ist, 
dann teilen die mir das mit und liefern ungefragt nach. Ist auch eine 
Möglichkeit.

[kopfkratzer (Gast)]

kopfkratz
Tja nun, das hängt halt davon ab in welchem Kontext das ganze 
stattfindet.
Das probateste Mittel in OO ist Du "schmeißt" eine Exception, dafür ist 
der Zweig

try MeinObjekt.Machwas()
  catch MeineException
  {
   cout << "Uuups Hiltis sind alle !" << endl;
  }

gemacht.
Du kannst aber auch ganz klassisch einen Rückgabewert definieren:

if(!MeinObjekt.Machwas())
  cout << "Uuups Hiltis sind alle !" << endl;

Und wenn Du statt boolean eine eigene Klasse zurückgibst kannst Du damit 
dann fast alles erschlagen was mit Hiltis, Stützstrümpfen und Rosmarin 
zu tun hat :-P