Merge branch 'master' of git.manuel.mausz.at:/foop

1 files changed, 7 insertions, 1 deletions

diff --git a/eiffel-fragen/eiffel-fragen.txt b/eiffel-fragen/eiffel-fragen.txt
index 3fac8d0..3dac09d 100644
--- a/eiffel-fragen/eiffel-fragen.txt
+++ b/eiffel-fragen/eiffel-fragen.txt
@@ -26,6 +26,12 @@ Bei CHILD wird der interene Zustand allerdings negativ, sichtbar durch ch.get().
 ----------------------------------------------------------------------------------------- 
 - Eiffel erlaubt kovariante Eingangsparametertypen. Unter welchen Bedingungen führt das zu Problemen, und wie äußern sich diese? Können Sie ein Programm schreiben, in dem die Verwendung kovarianter Eingangsparametertypen zu einer Exception führt?
 
- 
+Kovariante Eingangsparametertypen verstoßen gegen die Untertypsbeziehung, sogenannte Catcalls können auftreten:
+
+Kovariante Eingangsparameter werden in der Methode add_authorized_signer verwendet. 
+ACCOUNT.add_authorized_signer erwartet eine PERSON, RETIREEACCOUNT.add_authorized_signer einen RETIREE. Das Codefragment in bank.e Zeile 56 führt zu einem Laufzeitfehler. Ohne Upcast würde ein Compilezeitfehler folgen (z.B. RETIREEACCOUNT.add_authorized_signer( student_instanz ) ), bei einem Upcast zu ACCOUNT erkennt der Compiler den Fehler nicht mehr und es wird eine "Catcall detected"-Exception geworfen.
+
 ----------------------------------------------------------------------------------------- 
 - Vereinfachen kovariante Eingangsparametertypen die Programmierung? Unter welchen Bedingungen ist das so?
+
+Kovariante Eingangsparametertypen können bei kovarianten Problemen, wie zum Beispiel bei binären Methoden hilfreich sein. Bei kontravarianten Eingangsparametern muss sich der Entwickler mit Patterns wie "visitor" oder type checks behelfen. Eine equals Methode könnte man in Eiffel mit kovarianten Eingangsparametern realisieren, die Untertypsbeziehung wird, wie bereits erwähnt, aufgelöst. Ist eine Untertypsbeziehung nicht notwendig, stellen kovariante Eingangsparametertypen kein Problem dar.