Assertions As Contracts, Explicit or Implicit

Daniel Read — Mon, 27 Feb 2006 16:33:52 -0800

Thanks for this first post to your new developer.* blog, Mario. I enjoyed it, and it provided some good food for thought. One reason I have been slow to respond with a comment is that I've been thinking about your post.

I like this idea of assertions as contracts. Where things get interesting, as you point out, is when the contract needs to change, but also in the degree of explicitness in the contract. If you're working in a language like Eiffel that has explicit design-by-contract and assertion mechanisms, or if you're working with a unit testing framework that in a way serves as this documentation, then the opportunity to make this part of the contract more explicit is greater than it might be in another language, where an API reference document or JavaDoc/NDoc comment might be the only place something like that gets documented.

I remember from the many hours I spent working in Visual Basic 6 that, while it had a certain power in a lot of other areas, one of the areas it was lacking was language-level support for assertions. There was an Assert() method on the intrinsic Debug object, but that only worked while physically running the program in the interactive debugger (that is, you could not do a deployable debug build with the assertions enabled). That said, I still implemented my own assumption validation and input checking code in any kind of component methods or property setters I coded.

I wonder if the lack of consistency of idea or implementation across languages and tools for assertions, preconditions, and the like has contributed to a lack of knowledge or momentum for this technique. Outside of certain language or methodology communities where contracts and/or assertions are part of the modus operandi, I would posit that these concepts are either non-existent or little used.

What I mean is, they are not being used consciously, in a systematic and explicit way. For example, someone could argue that an interface in any object oriented language represents a contract, but that does not mean the program designer and/or maintainer is thinking of them that way. As another example, .NET has assertion mechanisms, but I don't hear much about people using them--and I've never encountered them in anyone else's code. (While doing a quick search just now, I found this very nice explanation /critique of .NET assertions.)

Another idea that seems useful is that the patterns and conventions inherent in your implicit contract (the assertions and preconditions) should align with the patterns and conventions of the explicit contract. I would say this is true regardless of whether the language being used offers an explicit mechanism for contracts and/or assertions, as Dr. Meyer's Eiffel language does. The idea is that a person should to some degree be able to guess what the assertions would be based on your patterns.

I've not had the pleasure of reading the classic Bertrand Meyer book you reference. That's probably something I should remedy.

Thanks again, Mario.

Welcome.

Dan

P.S.
Mario and I have been going through the editing process for an article written by Mario that will appear in developer.* in the near future. The article is about best practices and strategies for O/R mapping layers and persistency APIs [note added later: here is the article]. Mario lives in Belgium, land of the best beer in the world. I'm sure there are many other great things to say about Belgium, but I've never had the pleasure of a visit, and the wonderful beer--and chocolate--is my only frame of reference. MMmmmmmmm....Westvleteren...

The Dark Side of Assertions

Mario Van Damme — Thu, 23 Feb 2006 06:25:10 -0800

Although the title might allude to a phrase in the newest Star Wars movie, the context of this article is more serious. First of all, it is good that people read books. However, they need to be interpreted correctly. How often arenâ€™t design patterns misused for the fun of it? This blog article is about another aspect which made its revival with test driven design (TDD) and extreme programming (XP). This article will focus on the â€˜dangerâ€™ that lies in the unmanaged use of assertions.

developer.* Blogs - The Dark Side of Assertions - Comments

Assertions As Contracts, Explicit or Implicit

The Dark Side of Assertions