Binarymist

Part 1

Two design principle’s I believe go hand in hand are

1. Dr. Barbara Liskov’s Liskov Substitution Principle (LSP)
2. Dr. Bertrand Meyer’s Design by Contract (DbC)

Lets keep our Object Oriented relationships adhering to the LSP and the DbC.
The LSP and the DbC provide both theory and practical guidelines of how we as software engineers can design…

• Hierarchical components that behave the same across all layers.
• Systems that produce predictable results on a layer, from changes made on another layer (providing architecture that can be reasoned about).
  As programmers, we need to be able to make correct assumptions about the behaviour of abstract data types and their derivatives.
  LSP and DbC provide us with the ability to create intuitive class hierarchies that support the object oriented architectural reasoning process.
• Extensible code. Ability to add functionality without having to change existing code, but rather extending it.

LSP

The LSP states that you shouldn’t inherit from a base class unless the derived class truly “is a” more specific version of the base class (Liskov 1988).
Subtype objects must be behaviourally substitutable for supertype objects.
Programmers must be able to reason correctly about and rely upon the behaviour of subtypes using only the specification of the supertype behaviour.

Robert C. Martin wrote this excellent article on LSP.
Which I found here along with many other great articles.

Andy Hunt and Dave Thomas summarise LSP like this: “Subclasses must be usable through the base class interface without the need for the user to know the difference.”
In other words, all the routines defined in the base class should mean the same thing when they’re used in each of the derived classes.

As Steve McConnell in Code Complete puts it:
If you have a base class of Account and derived classes of CheckingAccount, SavingsAccount, and AutoLoanAccount.
A programmer should be able to invoke any of the routines derived from Account on any of Account’s subtypes without caring about which subtype a specific account object is.

If a program has been written so that the LSP is true, inheritance is a powerful tool for reducing complexity because a programmer can focus on the generic attributes of an object without worrying about the details.
If a programmer must be constantly thinking about semantic differences in a subclass implementation, then inheritance is increasing complexity rather than reducing it.
This goes against software’s primary technical imperative of managing complexity.
Suppose a programmer has to think this
“If I call the InterestRate() routine on CheckingAccount or SavingsAccount,
it returns the interest the bank pays,
but if I call InterestRate() on AutoLoanAccount I have to change the sign because it returns the interest the consumer pays to the bank.”
According to LSP, AutoLoanAccount should not inherit from the Account base class in this example
because the semantics of the InterestRate() routine are not the same as the semantics of the base class’s InterestRate() routine.

DbC

From my understanding. DbC provides constraints which enforce the LSP.
LSP is notional. DbC provides us with the practical approach.

.Net 4.0 gives us Code Contracts which directly support the DbC principle.
In looking at what the .Net framework 4.0 provides us with in the System.Diagnostics.Contracts namespace.
Bear in mind, this is not a language extension or a runtime extension. It’s just a library.
I think that using the static class’s in your code, that System.Diagnostics.Contracts provides would be a prime candidate for Aspect Oriented Programming.
It looks like the .Net CLR has support for AOP, although it doesn’t sound like it has been implemented very cleanly.
Have a look at this.
IMHO, when using AOP, the actual business code utilising the aspects, should not show any signs of the aspects (Code Contracts (in our case)).
Although it looks like there are some open source alternatives that do the job quite nicely.
Anyway, without diving into AOP, lets save it for another post and move on.

DbC is actually a registered trademark of Eiffel Software.
Bertrand Meyer when designing the Eiffel programming language came up with this term.
DbC provides us with class invariants, preconditions and postconditions.

C# for artists by Rick Miller has a good explanation of these.

Class Invariant

A class invariant is an assertion about an object property that must hold true for all valid states the object can assume.
For example, suppose an airplane object has a speed property that can be set to a range of integer values between 0 and 800.
This rule should be enforced for all valid states an airplane object can assume.
All methods that can be invoked on an airplane object must ensure they do not set the speed property to less than 0 or greater than 800.

Precondition

A precondition is an assertion about some condition that must be true before a method can be expected to perform it’s operation correctly.
For example, suppose the airplane object’s speed property can be incremented by some value and there exists in the set of airplane’s public interface methods one that increments the speed property any where from 1 to 5 depending on the value of the argument supplied to the method.
For this method to perform correctly, it must check that the argument is in fact a valid increment value of 1,2,3,4, or 5.
If the increment value tests valid then the precondition holds true and the increment method should perform correctly.
The precondition must be true before the method is called, therefore it is the responsibility of the caller to make the precondition true, and the responsibility of the called method to enforce the truth of the precondition.

Postcondition

A postcondition is an assertion that must hold true when a method completes its operations and returns to the caller.
For example, the airplane’s speed increment method should ensure that the class invariant speed property being 0<=speed<=800 holds true when the increment method completes its operations.

–

Code Contracts can run on .Net 4.0 or previous versions.

Code Contracts as a whole include

1)   Static methods from the Contract class

• Express assumptions and constraints, I.E. the object invariants, pre and post conditions.

2)   Static analyzer or static checker

• Provide compile-time analysis.
• Checks for implicit contracts, such as null dereferences and checking array bounds, as well as the explicit developer provided contracts.
• Only available in Microsoft’s Premium edition or above of Visual Studio.

3)   Runtime analyzer or binary rewriter

• modifies the IL by injecting the contracts.
• performs runtime checking.

Once you’ve installed either the Standard or Premium Edition of the managed code contracts from DevLabs.
Projects within Visual Studio will now have an extra property pane entitled “Code Contracts”.
This pane provides configuration options for both static and runtime contract checking.

–

–

I think the idea is that if your project is targeting:

1. A .Net framework version prior to 4.0, the System.Diagnostics.Contracts namespace is in the Microsoft.Contracts.dll.
2. The .Net framework version is 4.0, the System.Diagnostics.Contracts namespace is in the mscorlib.dll.

Tags: Architecture, Microsoft

This entry was posted on October 11, 2010 at 23:44 and is filed under Architecture, Microsoft. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.