eiffel fragen 4, 5

1 files changed, 7 insertions, 1 deletions

diff --git a/eiffel-fragen/eiffel-fragen.txt b/eiffel-fragen/eiffel-fragen.txt
index 62fcef2..7ccb881 100644
--- a/eiffel-fragen/eiffel-fragen.txt
+++ b/eiffel-fragen/eiffel-fragen.txt
@@ -20,6 +20,12 @@ Die Zusicherungen wirken sich zwangsläufig stark auf die Laufzeit aus. Sie sind
 ----------------------------------------------------------------------------------------- 
 - 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.