In the past weeks, I’ve released Light.GuardClauses 3.0 and 3.1. This post discusses new features and breaking changes of these versions.
Everything on Tag: Design by Contract
I just released version 2.0 of Light.GuardClauses. This version brings new features and some breaking changes. Let’s check them out!
Last year in May, I published Light.GuardClauses, a .NET Portable Class Library that lets you perform easy precondition checks at the beginning of your methods. Last Wednesday, I released v1.3 which brings the following new features to you…
My previous two posts about Bertrand Meyer’s Design by Contract (DbC) were mainly introductions to pre- and post-conditions and class invariants and how they can be implemented in C# – in this one we’ll check out what implications DbC has if it is combined with the inheritance mechanism of object-oriented programming languages.
If you happen to speak German, you can watch the video of my latest talk at the .NET User Group Regensburg which I held on last Monday, the 25th. of January. In it, we discuss the basics of Design by Contract with its Pre- and Post-Condtions, Class Invariants, and Variants and Invariants for loops as well as a framework called Code Contracts that provides functionality to introduce DbC in .NET. Furthermore, we check out alternatives to Code Contracts and the importance of executable specifications.
In one of my last posts, I discussed the basics of Bertrand Meyer’s Design by Contract, namely pre- and post-conditions on methods. These Boolean assertions are used to check if the caller supplied valid arguments and performed the call while the target object was in a valid state, as well as to verify that the method produced the correct return value and/or side effects after it executed completely. This allows us to give semantical meaning to methods on our objects.
In one of his recent posts, Mark Seemann argued that you should not use the internal modifier for types and their members, because this decreases the testability of your code. While I totally agree with him on the subject, I want to highlight another reason for not using internal: the extensibility of your reusable code bases.
I’m currently reading Bertrand Meyer’s “Object-Oriented Software Construction” (finally, I should say) and I’m absolutely amazed. Part of the reason I haven’t touched this book yet is its age: the second edition was released in 1998. A book that is now 17 years old (the first edition is even ten years older) – what could I learn from it, especially in a field like software development where things change relatively fast?
Well, I was totally wrong. Not only are the topics Bertrand Meyer addresses in his book still relevant for OOP today, but more importantly he describes concepts that are not fully supported by popular object-oriented languages like C++, C#, or Java, although they are deemed necessary to achieve the main goals of software quality with OOP according to Meyer.
One of these concepts is Design by Contract. And the best thing is that you probably apply it in your daily programming already, although not to such an extend as Meyer intends you to. So let’s check what Design by Contract actually means.