A small article about design by contracts in C# dotnet 4. The comments after the article show some interesting critique to the DbC that look more interesting than the article itself:
http://www.infoq.com/news/2008/11/Code-Contracts That critique is right, but wrong too. Contracts are a kind of type system. They put limits and add rigidity between the interfaces (not meant in their D language meaning) between code subunits. Dynamic type systems allow faster updates when parts change, while strict type systems, unittests and Dbc increase your confidence that the code does what you want and reduce unwanted interactions between subsistems of your program, and at the same time they introduce long-distance coupling among those subsystems. So in the end life is about trade-offs. Even unittests may add such rigidity that has a cost. If you have to write code that guides the Space Shuttle you want it to be perfect, and you want to use DbC enforced statically, while if you want to write software that deals with ever mutating commercial realities, you prefer something like C# or Python that allows you to change your code with less work. D looks designed more for numerical code, where rules don't change or change slowly, and less fit for commercial code that needs to be changed often. ------------------------ That article shows this C#4 code: Public Sub Add(value as Object) Contract.Ensure(Count = Contract.OldValue(Count) + 1) If they have found a way to implement that in C# then I think it may be possible to do in D too :-) Old values are useful in DbC. Bye, bearophile
