eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Microsoft has implemented the design-by-contract approach to software development for .Net developers.
In a solution called Code Contracts for .Net, which came out of Microsoft Research, Microsoft is providing a design-by-contract mechanism for .Net programmers.
Design by Contract (DbC) is an approach to designing that proposes that software designers should define formal, precise and verifiable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a business contract. In other words, the basic idea is that software components can define “contracts” about their behavior, inputs, state change and other things. The term was coined by Bertrand Meyer, creator of the Eiffel programming language.
In a blog post, Microsoft Senior Vice President, Developer Division, S. Somasegar said Microsoft’s Dev Labs released Code Contracts for .Net to enable programmers “to provide method preconditions and postconditions that enrich existing APIs with information that is not expressible in the type systems of .Net languages. Additionally, contracts specify object invariants, which define what allowable states an instance of a class may be in (i.e. its internal consistency).”
Somasegar also said:
““The contracts are used for runtime checking, static verification and documentation generation. Contracts also allow automatic documentation checking and improved testing. Code Contracts for .Net currently consists of three components: the static library methods used for expressing the contracts, a binary rewriter and a static checker.”“
Moreover, Somasegar said developers also can use Code Contracts directly in Visual Studio. Indeed, “Installing the Code Contracts MSI enables the ‘Code Contracts’ tab in project properties where you can set your preferences for Code Contracts use,” Somasegar said. “For configurations where the runtime checking is not performed, the library methods are compiled away (via conditional compilation attributes on their definitions — a very neat feature of .Net!) so that your code pays no performance penalty at all for contracts that you do not want executed.”
In a conversation about the new DbC support for .Net, a prominent Java developer in the industry told eWEEK, “It would be nice to have this as part of a modern, mainstream environment.”
Eric Newcomer, an independent consultant and former chief technology officer at Iona (now part of Progress Software), said of Microsoft’s move, “It looks like they are extending interfaces for pre and post conditions, to extend the agreement level between client and server programs — or service requester and provider more correctly, I suppose. The interface by itself defines only a limited agreement, adding pre and post conditions, and further documentation to a ‘contract’ extends what it is possible to check on.”
Further, Newcomer, who also is a Microsoft architecture Most Valuable Professional (MVP), said:
““Customers always have the general issue of needing to agree on more than what can be put into an interface. You have policies and service level agreements, but you also have ownership issues — i.e. who owns the data, who has the responsibility for changing the design etc., and typically you have to write down a lot of these formal agreements when doing SOA [Service Oriented Architecture] stuff — sometimes mentioned as the governance aspect I suppose — and by extending what you can code and test for, you extend what can be put into the software, and at the same time decrease what you have to rely on associated documentation for.” “