Zusicherungen in C#???
Hallo zusammen.
Hab schon ausgiebig gesucht, aber keine Antwort auf die Frage gefunden.
Es muss doch in C# eine Möglichkeit geben, Zusicherungen einzubauen. D.h., eine Aussage über den Zustand eines Programmablaufs. Erreicht der Programmablauf eine Zusicherung, muss diese erfüllt sein, sonst ist das Programm fehlerhaft.
Gibt es dafür speziele Konstrukte? Oder muss man das irgendwie über Ausnahmebehandlung lösen?
Hoffe, ihr könnt mir helfen!
MfG,
Max
Mmh, ich verstehe nicht wirklich was für ein "Mechanismus" eine "Zusicherung" sein soll? Eine Art QM? Nenn' mal ein Aquivalent in einer anderen Sprache, falls es sowas gibt.
Naja, um z.B. Vor- und Nachbedingungen von Methoden zu definieren.
Um die Methode ausführen zu können, muss das und das gelten. danach muss das und das gelten.
Geht glaub ich auf das sog. "Designing by Contract" zurück.
Äquivalent z.B. in Eiffel: requires, **ensures **und invariant.
In Component Pascal ist es assert, in Java glaub auch.
Gruß
Hi,
Du meinst sicher ein Assert, wie es auch in C++ benutzt wird.
Gibt es unter Debug.Assert(Condition).
Namespace using System.Diagnostics;
Tschüss
Hallo Beatmax,
sorry, das kann dann aber nur heißen, dass du vorher nicht in die Doku geguckt hast. Denn den Suchbegriff assert kanntest du ja. Vor dem Posten in die Doku zu gucken, erwarten wir aber. Siehe [Hinweis] Wie poste ich richtig? Punkt 1.
herbivore
Hallo,
Eine Unterstützung für design-by-contract ist im .NET Framework nur begrenzt eingebaut. Es gibt die Klassen Trace und Debug (in System.Diagnostics), die mit Assert-Methode aufwarten können. Diese könnten also durchaus dafür verwendet werden. Wenn du wirklich deine Pre- und Postconditions und Invarianten im Code checken willst, empfehle ich dir aber, eigene Klassen dafür zu implementieren. Ich habe das auch mal gemacht: Assert, Require und Ensure Klassen, jeweils mit einer Vielfalt an Methoden (IsNull, IsNotNull, AreEqual, AreSame, IsTrue, IsFalse usw. - im Prinzip ein Nachbau der NUnit-Assert-Klasse). Der Vorteil, wenn du das so aufteilst ist, dass du für jede Klasse andere Conditional-Attribute verwenden kannst, um z.B. die Postcondition-Checks separat auszuschalten. Außerdem kannst du eigene (und unterschiedliche) Exceptions werfen und einheitliche Fehlermeldungen generieren.
Ich muss allerdings sagen, dass ich diese Klassen eigentlich kaum noch nutze. Preconditions checke ich mittlerweile größtenteils nicht mehr "nur" noch durch ein "aufgesetztes" Require, sondern als Teil der Businesslogik mit entsprechenden Exceptions. Postconditions prüfe ich vor allem mittels Unittests im Zuge von Testdriven Development. Da meine Anwendungen in der Regel nicht performancekritisch sind, hätte ich keinen Vorteil davon, Pre/postconditionchecks für Releasebuilds auszuschalten. Was von design-by-contract übrige bleibt ist dann vor allem noch die Dokumentation der Methoden. Es kann sein, dass ich ab und an ein Assert dazwischen streue, allerdings eher wegen des selbstdokumentierenden Effekts. Dafür reicht dann auch ein Trace.Assert oder Debug.Assert.
Grüße,
Andre
Vielen Dank für die **konstruktiven **Antworten!
Das mit der eigens implementierten Klasse ist natürlich ne tolle Sache, aber ich denk, das einfach Assert reicht mir ersteinmal.
Merci baucoup!
Max
Hallo Beatmax,
vielen Dank, dass du meine Antwort als konstruktiv anerkennst. Genau so war sie gemeint!
herbivore