How to use it in C #-design by contract)

Contract-based Design --- DBC Design by contract is a simple and powerful technology that focuses on recording (and agreeing) the rights and responsibilities of software modules in a document to ensure Program Correctness. Simply put, the statement is recorded in the document and verified to ensure that the program can do what it declares to do.

EiffelI developed this concept and implemented it well. Can more popular languages like Java &. Net be supported?DBCWhat about it? I checked the information and used JavaIcontractSuch a toolPre-processor(Perprocesseor), Processing is embedded as a special comment in the originalCodeThe. NET Framework hasPre-processor(Perprocesseor) And supportsPreprocessing commands(For example, # If, # Elif, # define), can. Net be directly supported without using other tools?DBCWhat about ??

After a while, I found that. Net does not have a separatePreprocessor,Preprocessing commandsIt just makes you feel like there is onePreprocessor, So it cannot be implemented well.DBCInPrerequisites(Precondition ),Post Condition(Postcondition) andUnchanged(Invariant). That. Net does notPreprocessorIt cannot be implemented.DBC? The answer is not absolute, becauseDBCThe main content isAssertions(Assert), so we can useAssertions(Assert) to simulate this:

The percondition code in icontract is as follows:

/**
* @ Pre F> = 0.0 // @ pre defines percondition. Make sure that the F parameter must be greater than or equal to 0.
*/
Public float SQRT (float f ){...}

C # can be simulated as follows:
 
Public float SQRT (float F)
{
System. Diagnostics. Debug. Assert (F> = 0, "parameter F <0 ");
......
}

Postcondition can be implemented similarly:

Icontract:

/**
* @ Pre F> = 0.0
* @ Post math. Abs (return * return)-f) <0.001
*/
Public float SQRT (float f ){...}

C #:
Public float SQRT (float F)
{
System. Diagnostics. Debug. Assert (F> = 0, "parameter F <0 ");
......
System. Diagnostics. Debug. Assert (math. Abs (result * result)-f) <0.001 );
Return result;
}

This can also be done in invariants, so I will not write it here.

As mentioned above, useAssertions(Assert) ImplementationDBCIt is always a simulated implementation, that is, we cannot use assertDBCThe main reason for doing everythingAssertions(Assert) It cannot be inherited down the hierarchy. This means that if you reset the basic class method of a contract, you must manually copy your modifications to its underlying class.

OnlyAssertions(Assert) ImplementationDBCAlthough the functions are incomplete, it is still necessary to control the input and output parameters according to the initial simple design, this greatly increases the program's "security" (reduces the chance of a bug), allowing your program to complete a quality leap.

Finally, I will list the examples in [the pragmatic programmer] (some of them have been modified as appropriate) and they exist in our common sense. with these assertions, you often think that there will be no errors, and there are bugs. it is easy for us to fall into such a psychological state as "it cannot happen.

1. A month cannot be less than 28.
2. in C #: A = 2; B = 3; if (a + B! = 5) Exit ();
3. No inner angle or triangle not equal to 180 degrees.
4. There is no minute greater than 60 seconds.
5. in C #: (A + 1) <=;

P.s: I think the abstract class is also an interface we implement.DBC, It fully compliesDBCAnd check the contract implementation during the compilation period.