- Wie hoch ist der Aufwand in Eiffel, um Zusicherungen im Programmcode zu formulieren?
Eine Zusicherung ist nur eine Zeile lang und der Block von Zusicherungen wird durch nur ein Wort (require, ensure, invariant) eingeleitet. Der Schreibaufwand ist also sehr gering.

Außerdem können die Zusicherungen als Schnittstellendefinitionen verwedet werden. Daher verursachen sie, aus dieser Perspektive, keine zusätzlichen Aufwand wenn sie eine andere Art von Schnittstellendefinition ersetzen.

(siehe http://archive.eiffel.com/eiffel/nutshell.html "What's this "Design by Contract" thing?")

 
----------------------------------------------------------------------------------------- 
- Wie stark wirkt sich die Überprüfung von Zusicherungen auf die Laufzeit aus?
Die Zusicherungen wirken sich zwangsläufig stark auf die Laufzeit aus. Sie sind jedoch normalerweise nur während der Entwicklung eingeschaltet. In den produktiv eingesetzten Binaries sind sie typischer weise ganz abgeschaltet. Es besteht auch die Möglichkeit sie für jede Klasse einzeln auf verschiedene Level (no check, preconditions only, preconditions and postconditions, everything) einzustellen.

(siehe http://www.faqs.org/faqs/eiffel-faq/ "How fast do Eiffel applications run?")

 
----------------------------------------------------------------------------------------- 
- Vorbedingungen dürfen im Untertyp nicht stärker und Nachbedingungen nicht schwächer werden, um Ersetzbarkeit zu garantieren. Der Eiffel-Compiler überprüft diese Bedingungen. Ist es (trotz eingeschalteter Überprüfung von Zusicherungen) möglich, diese Bedingungen zu umgehen? Wenn ja, wie?

Ja, indem ein "redefine" von Metodhen gemacht wird, die einem "ensure" verwendet werden kann dieses schwächer werden ohne, dass der Compiler es merkt.

Im Bsp:
Der interne Zustand von "item" dürfte nie negativ werden, daher auch ct.get() nie einen negativen wert liefern.
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.