If you ask people familiar with Object Oriented Design which are the most important concepts of the paradigm to them, you will surely hear things like classes, inheritance, polymorphism. Some may talk about genericity; somebody may even mention encapsulation or information hiding.

In fact, many designers use the words encapsulation and information hiding interchangeably.

Encapsulation

In his book  Fundamental Of Object Oriented Design in UML Meilir Page-Jones gives the following definition for encapsulation:

Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name.

Single name is here the key word to get an insight of what encapsulation is about: a subroutine (or function as we call it nowadays), for example, is a name that refers to a unit of code. Something that instead of being repeated over and over in the source code is factored out in a single place.

As such the function is the simplest level of encapsulation and abstraction: a designer can refer to it by name as a single entity and even forget the details of the internals and only remember its interface.

Encapsulation in the object oriented world expands on this concept from the subroutine level to the object level: attributes that represents the state of an object and the methods that work on them are packaged into an object type.

Information Hiding

The concept of information hiding is very similar and was first introduced by Parnas in his seminal paper “On the Criteria to Be Used in Decomposing Systems Into Modules” (pdf) almost 40 years ago.

Parnas used the term discussing about which criteria lead to good modularity in structured programming:

every module in the [...] decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.

As you see, here also we talk about some separate entity or module which has some responsibility that we need fulfilled, and we are not interested about how it is fulfilled. But the emphasis here is a bit more about hiding the details from other modules (or objects in the OO world).

Information hiding gives the designer the freedom to modify how the responsibility is fulfilled by a module/object. This is especially valuable at points where the design (or even the requirements) are likely to change.

Uncle Bob Helps Explaining the Difference

Maybe one of the best example explaining the difference between encapsulation and information hiding can be found in Uncle Bob’s most recent book Clean Code (even though the author was not talking about these 2 concepts explicitely).

The following type is merely encapsulated: we have created a concept representing a geometrical concept (the point in a 2D space).

public class Point
{
    public double x;
    public double y;
}

The following type, on the other hand, is an example of information hiding applied to the same concept:

public interface Point
{
    double GetX();
    double GetY();
    void SetCartesian(double x, double y);
    double GetR();
    double GetTheta();
    void SetPolar(double r, double theta);
}

In this second example, the actual implementation is completely hidden: the client doesn’t know whether the internal representation of the point is in rectangular or polar coordinates.

If you are curious and want to know more, you can refer to the following wiki for more opinions on the differences (or lack thereof) between encapsulation and information hiding.

Photo by Leo Reynolds.

I recently embarked on a journey to read (or re-read) all the great classic books in the software literature.

The Pragmatic Programmer is one of those books which is usually included in the recommended readings for a software developer, and deservedly so. The book, released in 1999, has been so successful that the two authors, Andrew Hunt and David Thomas, have since created their own publishing company, the Pragmatic Bookshelf (with titles spanning a broad range of programming topics).

This book must really have been a breakthrough when it hit the bookstores about 10 years ago. 1999 is one year before Kent Beck released his seminal book Extreme Programming Explained: Embrace Change which exposed the agile software process to the masses. Both Andrew Hunt and David Thomas originally signed the Agile Manifesto, together with Kent Beck himself and a few others, and it shows. But it would be dismissive to describe this as a book on agile since it’s much more.

The book is structured as a series short 46 sections. Each section has challenges and even exercises where appropriate. It touches on design concepts such as orthogonality, decoupling, DRY (which it coined), Domain Specific Languages, Design By Contract, Metaprogramming, Refactoring; it has pages on process topics like build automation, “design to test”, test automation, estimation, requirements collection.

But where the book really shines is where it shows you how to “become a better programmer” (today we might say a software craftsman) and to take pride from it.

The pragmatic programmer is an early adopter, is inquisitive and realistic, and tries to be “familiar with a broad range of technologies and environments“.

The pragmatic programmer takes responsibility, values quality but recognizes when the software is “good enough”. The pragmatic programmer is a continuous learner (the “learn at least one new language every year” advice is often quoted), thinks critically about what he reads and hear, and knows how to communicate. The books explains how you can build these qualities.

The sections that I enjoyed the most is when the authors discuss about tools: the pragmatic programmer prefers working with plain text (the book itself it’s been written from XML transformed into TeX), masters a shell (command line) which he/she can program, knows at least one text manipulation language (e.g. Perl) and how to generate code from metadata.

Even though the recent reprints have links to later tools like JUnit, Ant, etc… still a few parts of the book begin to show its age. For example the authors suggest to pick one text editor (e.g. Emacs or VI) and become a power user (not just know the keyboard shortcuts but also how to extend it to suit your needs). There used to be a time when you could spend your whole working day inside Emacs: you could edit and build your programs, open a shell, handle emails and browse newsgroups, edit text documents (with LaTeX for example), even play games. As much as I love Emacs, I believe today it’s virtually impossible to beat the productivity gains you can get with specialized IDEs like Visual Studio or Eclipse, with their intellisense and plug-in ecosystems.

All in all, the Pragmatic Programmer is easily one of the best book on software development I have ever read. It has really inspired me to continue my journey to become a “better programmer”. Thanks to this book, I have now in my action list: learn a scripting language (Ruby?); learn a functional language (F#?); learn how to use a shell in the Windows environment (PowerShell?); read a book on usability; read a book on the human side of software development (“Peopleware”?). A lot of things. A lot of fun ahead.

The Problem of Circular References

Recently I had to model a tree-like structure using a variation of the GoF composite design pattern and to pass this class to a WCF service for further processing.

The class has circular reference as described by the following drawing:

Therefore off I went to naively create my DataContract along the following lines:

[DataContract(Namespace = "http://schemas.acme.it/2009/10"]
public class Node
{
	[DataMember(Name="Children", Order=2)]
    private IList<Node> children;

    [DataMember(Name="Id", Order=0)]
    public string Id { get; set; }

    [DataMember(Name="Parent", Order=1)]
    public Node Parent { get; set; }

    public Node()
    {
        children = new List<Node>()
    }

    public void AddChild(Node node)
    {
        this.children.Add(node);
        node.Parent = this;
    }

    public IList<Node> Children
    {
        get
        {
            IList<Node> result = new List(this.children);
            foreach (Node child in this.children)
            {
                foreach (Node innerChild in child.Children)
                {
                result.Add(innerChild);
                }
            }

            return result;
        }
    }
}

Unfortunately at run time I was greeted by the following exception:
Object graph for type 'System.Collections.Generic.List`1[[Node ...]]' contains cycles and cannot be serialized if reference tracking is disabled..

The Solution

Reading around I realized that up until some time ago you had to implement your own DataContractSerializer (see for example this post by Sowmy Srinivasan).

Luckily, it turns out that with NET 3.5 SP1 everything is much simpler: you just have to use the IsReference parameter in the DataContract attribute, as follows:

[DataContract(Namespace = "http://schemas.acme.it/2009/10", IsReference=true)]
public class Node
{
    // everything same as in the example above.
}

The Catch

For some reason, if you turn on the IsReference attribute, then you cannot set the IsRequired attribute to true on any DataMember of the DataContract. The reason is somehow explained here.

In my previous post Service Locator Pattern in C#: A Simple Example I introduced a fairly basic implementation of this pattern. In this post I will address one of the limitations of that implementation, introducing a form of lazy initialization.

Defining Lazy Initialization

Lazy initialization improves the performance of object creation, deferring long running initializations until they are really needed.

Suppose for example that some of the fields of an object need to be read from the database. If a client never access those fields, accessing the database to retrieve those fields has been useless and it has just made object initialization slower (often by a considerable factor).

Martin Fowler credits Kent Beck with the introduction of the lazy initialization pattern, and in PoEAA book he describes it in the following way:

The basic idea is that every access to the field checks to see if it’s null. If so, it calculates the value of the field before returning the field. To make this work you have to ensure that the field is self-encapsulated, meaning that all access to the field, even from within the class, is done through a getting method.

Fairly simple.

The Improved Service Locator

The following is the improved version of the service locator which uses lazy initialization of the services.

internal class ServiceLocator : IServiceLocator
{
    // a map between contracts -> concrete implementation classes
    private IDictionary<Type, Type> servicesType;

    // a map containing references to concrete implementation already instantiated
    // (the service locator uses lazy instantiation).
    private IDictionary<Type, object> instantiatedServices;

    internal ServiceLocator()
    {
        this.servicesType = new Dictionary<Type, Type>();
        this.instantiatedServices = new Dictionary<Type, object>();

        this.BuildServiceTypesMap();
    }

    public T GetService<T>()
    {
        if (this.instantiatedServices.ContainsKey(typeof(T)))
        {
            return (T)this.instantiatedServices[typeof(T)];
        }
        else
        {
            // lazy initialization
            try
            {
                // use reflection to invoke the service
                ConstructorInfo constructor = servicesType[typeof(T)].GetConstructor(new Type[0]);
                Debug.Assert(constructor != null, "Cannot find a suitable constructor for " + typeof(T));

                T service = (T)constructor.Invoke(null);

                // add the service to the ones that we have already instantiated
                instantiatedServices.Add(typeof(T), service);

                return service;
            }
            catch (KeyNotFoundException)
            {
                throw new ApplicationException"The requested service is not registered");
            }
        }
    }

    private void BuildServiceTypesMap()
    {
        servicesType.Add(typeof(IServiceA),
            typeof(ServiceA));

        servicesType.Add(typeof(IServiceB),
            typeof(ServiceB));

        servicesType.Add(typeof(IServiceC),
            typeof(ServiceC));
     }
}

We are now maintaining two separate maps:

• servicesType maps an interface describing a service to a type T that implements that interface.
• instantiatedServices maps an interface to an instantiated object of class T.

Both maps are initialized in the constructor. However only the first map is filled. Every time GetService is invoked, we check whether a concrete implementation of that service has already been created. If not, we create that service implementation retrieving its constructor via reflection, and we put a reference to that implementation in the instantiatedServices map.

For this to work, the service implementation needs to expose a default (parameterless) constructor.

If services creation time is significant, lazy initialization can save you quite some time during application start up, with very little cost in terms of increased complexity.

Next article in the series: A Singleton Service Locator

A Service Locator is a common design pattern that allows decoupling clients of services (described by a public interface) from the concrete class implementing those services. Martin Fowler has a great introduction on the topic in his Inversion of Control Containers and the Dependency Injection pattern.

What follows is a very simple service locator implementation in C# based on generics.

Let’s start defining the contract of a service locator.

public interface IServiceLocator
{
    T GetService<T>();
}

Now let’s see a very simple implementation of this contract:

class ServiceLocator : IServiceLocator
{
	// map that contains pairs of interfaces and
	// references to concrete implementations
	private IDictionary<object, object> services;

	internal ServiceLocator()
	{
		services = new Dictionary<object, object>();

		// fill the map
		this.services.Add(typeof(IServiceA), new ServiceA());
		this.services.Add(typeof(IServiceB), new ServiceB());
		this.services.Add(typeof(IServiceC), new ServiceC());
	}

	public T GetService<T>()
	{
		try
		{
			return (T)services[typeof(T)];
		}
		catch (KeyNotFoundException)
		{
			throw new ApplicationException("The requested service is not registered");
		}
	}
}

As you can see,

• the constructor of the class registers all the available services in a dictionary. In our example, we have 3 different services accessible through IServiceA, IServiceB, and IServiceC. It is assumed here that ServiceA implements IServiceA and so forth.
• the generic GetService() method returns a reference the correct implementation fetching it from the dictionary

This is how a client would invoke the service:

IServiceLocator locator = new ServiceLocator();
IServiceA myServiceA = locator.GetService<IServiceA>();

The clients do not know the actual classes implementing the service. They only have to interact with the service locator to get to an implementation.

Improvements

This is as simple as it gets. There are several improvements that a real-world implementation of a service locator should consider (what follows is only a partial list):

• The service locator itself might be a singleton. There usually is no need to have two instances of a service locator.
• Lazy initialization of services might be considered. In the example above, the constructor creates new instances for all possible services; initialization might be deferred until some client actually requests a particular service.
• The mapping between interfaces and implementation might be more flexible using metadata (e.g. through application configuration files)

Next article in the series: Service Locator Pattern in C# with Lazy Initialization

The Liskov Substitution Principle

This is the third post on a mini-series about Microsoft Code Contracts and why you should use it to write more robust and reusable code.

After introducing pre and post-conditions and invariants, it’s now time to discuss one of the most powerful concepts of the Design by Contract, that is contracts inheritance. The importance of the interactions between contracts and inheritance is described in one of the cornerstone concepts of Object Oriented Programming, that goes under the name of the Liskov Substitution Principle:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

This is a definition of how polymorphism through inheritance is meant to work: it must always be possible to use an instance of a child class in lieu of a parent class without the client knowing about it.

Let’s make a simple example. Suppose we define a service to reverse the content of a string. We can have a simple implementation of that class in the following terms:

public class StringReverser
{
  public virtual string Reverse(string inputString)
  {
     // a simple algorithm optimized for
     // low memory consumption
  }
}

Notice how the Reverse method has been defined as virtual. This makes it possible to subclass and replace the implementation of the method with an algorithm that is faster (possibly trading off some memory; we are not concerned here with the nitty-gritty details of the actual implementation).

public class FastStringReverser : StringReverser
{
  public override string Reverse(string inputString)
  {
     // a fast algorithm implementation
     // using a bit more memory
  }
}

We introduce a factory whose responsibility is creating an object that knows how to reverse a string:

public class ReverserFactory
{
  public static StringReverser GetReverser()
  {
    // here we have the logic to decide which kind of Reverser to create
    return new StringReverser();
  }
}

Finally, we have client class that, for whatever reason, needs to reverse a string.

public class Client
{
  public void SomeMethod()
  {
    StringReverser reverser = ReverseFactory.GetReverser();
    string reversed = reverser.reverse("Contracts are fun");
    // do something with the reversed string
  }
}

In this case the Client class uses (unknowingly) an instance of a StringReverser class (which is the base class listed above). Since FastStringReverser is a subclass of StringReverser, if we rewrite the factory to return an instance of FastStringReverser, Client will continue to work:

public class ReverserFactory
{
  public static StringReverser GetReverser()
  {
    // now we return the fast implementation.
    // In a real world example, there will be some logic to decide
    // which class to instantiate according to the context,
    // configuration files, input parameters, etc...
    return new FastStringReverser();
  }
}

So here we see the LSP in action. Referring to the definition at the top of this post, we have the following correspondences:

• StringReverser represents type T (the base type)
• FastStringReverser represents type S (the sub type)
• Client represents P (the code using T or a subtype of T)

Note: here I have presented the example subclassing from a base class with a virtual method to match more closely the standard definition of the LSB. Even more common, though, is that T represents an interface and that two or more concrete classes implement that interface. The client will have a handle to such an interface and the actual implementation will be provided either by a factory method, service locator or through dependency injection.

The LSP is violated, for example, whenever a client class has some logic dealing with the particular type of the implementation (such as Run Time Type Identification: if the actual type is this, then do that, otherwise do that other thing – or something along this line).

LSP and Contracts

Unfortunately, there are much more subtle ways in which the LSP can be violated, even if the client code is “well behaving” as in the example above. The classical example goes under the name “A Square is Not A Rectangle”. According to geometry, a square is a rectangle, but when it comes to software design… it is not!

The basic problem is that a square has an additional invariant with respect to the rectangle, which is that all the sides are equal and because of that you cannot independently change the height and the width like you would do with a rectangle; so if you have a SetHeight and SetWidth methods in the Rectangle, the Square should override those so that the invariant is always maintained: when the height is set by a client, internally the width is also set and vice versa. But the client might not expect this to happen! The client might make assumptions like the following:

// use a factory to create a rectangle passing width and height
Rectangle r = RectangleFactory.GetRectangle(4,5);

// change the dimensions
r.Width = 10;
// verify new dimensions
Assert.AreEqual(r.Width, 10);
Assert.AreEqual(r.Height, 5);

r.Height = 12;
// verify new dimensions
Assert.AreEqual(r.Width, 10);
Assert.AreEqual(r.Height, 12);

It’s easy to see that if the factory returns a Square, which internally always adjust one side to be equal to the other one, some of the assertions would fail. This means that the expectations of the client of dealing with a Rectangle square are no longer met, and the LSP is thus violated.
A way to make it clear what really “being a rectangle” is meant to be is to introduce some contracts on the base class:

public class Rectangle
{
  private double width;
  private double height;

  public Rectangle(double w, double h) { width = w; height = h; }

  public virtual double Width
  {
    get { return width; }
    set
    {
      double oldHeight = height;
      width = value;
      // ensure that height has not changed
      Contract.Ensures(oldHeight = height);
    }
  }

  public virtual double Height
  {
    get { return height; }
    set
    {
      double oldWidth = width;
      height = value;
      // ensure that width has not changed
      Contract.Ensures(oldWidth = width);
    }
  }
}

Now, when it comes to inheriting from a class which specify some contracts, Design By Contract specifies the following behavioral subtyping:

• If a subclass overrides the behavior of a method of a base class (or implements and interface), the preconditions it specifies can only be equivalent to or weaker than the base class
• If a subclass overrides the behavior of a method of a base class (or implements and interface), the postconditions it specifies can only be equivalent to or stronger than the base class.

This mean that any potential subclass of Rectangle needs to satisfy the postconditions in each of his methods (and possibly add more). This explicitly rules out Square from being a candidate subclass (since a square cannot guarantee that changing one side does not affect the other).

It’s interesting to note that, quite symmetrically, the preconditions of a base class can only be weaker; this makes sense especially from the client perspective: if subclasses were allowed to require more stringent preconditions, a client might fail to meet some precondition and thus stop working when a service implementation is substituted with another, which is a clear violation of the LSP, which is all about transparency.

Specifying Contracts for Interfaces and Abstract Classes

In the example above, Rectangle was a concrete class with some virtual method. But how do you specify contracts with Microsoft Code Contracts for interfaces or abstract methods which do not have a concrete implementation?

For interfaces, you need to create a dummy class implementing the interface and link them through Attributes, like the following:

[ContractClass(typeof(IStringReverser))]
interface IStringReverser
{
  string Reverse(string s);
}

[ContractClassFor(typeof(IStringReverser))]
sealed class StringReverserContract : IStringReverser
{
  string Reverse(string s)
  {
    Contract.Requires(s != null);
    return String.Empty; // dummy return value
  }
}

Note how you have to use explicit interface implementation and the use of a dummy return value.

For abstract methods it’s similar:

[ContractClass(typeof(StringReverser))]
abstract class StringReverser
{
  public abstract string Reverse(string s);
}

[ContractClassFor(typeof(StringReverser))]
abstract class StringReverserContract : StringReverser
{
  public override string Reverse(string s)
  {
    Contract.Requires(s != null);
    return String.Empty; // dummy return value
  }
}

I urge you to refer to Microsoft Code Contracts documentation for more information on how to specify contracts for interfaces and abstract methods.

In a previous post we introduced Microsoft Code Contracts, and got an idea of what Design by Contract (DBC) is all about. It’s now time to introduce another powerful concept that complements and completes preconditions and postconditions when you specify the behavior of your object: class invariants.

Invariants define all those conditions (or predicates, if you will) that are guaranteed to be true for all objects of a particular class throughout its life-cycle: these invariants need first to be met during construction and continue to hold before and after methods invocations.

Let’s consider a very simple implementation of a class that represents a calendar date, specified by day, month and year:

public class Date
{
  public short Day { get; }
  public short Month { get; }
  public short Year { get; }

  public Date(short dd, short mm, short yy)
  {
    Day = dd;
    Month = mm;
    Year = yy;
  }

  public void Increment()
  {
    // some tricky code to increment the day,
    // month (if needed) and year (if needed)
  }
}

Oversimplifying, such an object has some obvious invariants, or conditions that must always be met:

• Day, Month, and Year may not be negative
• Day must be a number between 1 and 31 (let’s simplify and assume all months have the same days)
• Month must be a number between 1 and 12

These conditions must be true upon successful creation of a Date object and after each invocation of Increment().

With Code Contracts, one expresses invariants using a special method tagged with a [ContractInvariantMethod] attribute; it is usually named ObjectInvariant although this is just a convention: you can name it anything you like.

public class Date
{
  // ...
  // rest of the class as listing above

  [ContractInvariantMethod]
  protected void ObjectInvariant()
  {
    Contract.Invariant(this.Day >= 0);
    Contract.Invariant(this.Day <= 31);
    Contract.Invariant(this.Month >= 0);
    Contract.Invariant(this.Month <= 12);
    Contract.Invariant(this.Year >= 0);
  }
}

You are not allowed to put any other code but the invariants; the method must have a void return type and be protected (unless the class is sealed of course).

Invariants are checked at the end of every public method (including constructors and excluding finalizers and methods implementing IDisposable.Dispose()) – in our example, every time a client of this class invokes the Increment() method, the invariants will be checked.

Invariants, along with pre and postconditions, are inherited by subclasses. We’ll see how this fits in a sound object oriented design in the next post.

(zdwfg7nay2)

Design by Contract was first introduced by Bertrand Meyer, creator of the Eiffel programming language,  in his seminal book Object-oriented Software Construction. In a nutshell, DBC is based on the following principles:

• preconditions: a method imposes on the client a set of conditions that must be met in order for the method to be invoked successfully (think about parameters validation).
• postconditions: a set of properties are guaranteed by the method immediately after the execution (think about a return value that can only be positive, for example).
• invariants: a set of properties on the class are assumed to hold before the method starts and are guaranteed to hold after the method completes (think about a field of the class that may not be negative, for example).

A contract formalizes these three things. How can contracts, and defensive programming in general, help us developing better software? Bertrand Meyer explains it in this interview from 2003:

The main purpose of contracts is to help us build better software by organizing the communication between software elements through specifying, as precisely as possible, the mutual obligations and benefits that are involved in those communications. [...] relying on these notions—that is to say, making sure when you write software that don’t just write the implementation, but also write the more abstract properties underlying the implementation in the form of contracts—provides a greatly added software development experience in several respects. It helps ensure correctness in the first place, helps debugging, helps testing, helps ensure inheritance is properly handled, helps managers, provides a quite effective form of documentation, and a few others.

Up to now, only a few languages supported DBC natively, and C# was not one of those. With .NET 4.0 Microsoft fills this gap with Code Contracts. It’s possible to download Code Contracts for Visual Studio 2008 for the Standard Edition and the Team System edition.

A Basic Example

Let’s see a basic example of how one can use Contracts in a simple class. (to try this on your own you need to install Code Contracts from msdn web site). In this case I have a class with a static method that simply inverts the content of a string (the choice of the algorithm here is irrelevant).

[sourcecode language="csharp"]
using System;
using System.Diagnostics.Contracts;

namespace TestContracts
{
public class StringInverter
{
public static string Invert(string s)
{
// preconditions:
Contract.Requires(s != null);

// postconditions;
Contract.Ensures(Contract.Result<string>().Length == s.Length);

char[] reverted = new char[s.Length];
int i = 0;
foreach (char c in s)
{
reverted[s.Length - 1 - i ] = c;
i++;
}

return new string(reverted);
}
}
}
[/sourcecode]

The first thing to notice is that we have added a reference to the System.Diagnostics.Contracts namespace. This is where the new library is located. For this to work you have also to add a reference in your project to the Microsoft.Contracts assembly that has come with the Code Contracts installation.

The first method that we invoke on Contracts is a precondition that specifies that this method cannot accept an input string which is null (it would accept an empty string though). The second method is a postcondition asserting that this method guarantees that the string returned by this method will have the same size as the input string.

Obviously you are free to add more preconditions and/or postconditions if your domain logic requires so. But what exactly happens at run-time if either a precontion or a postcondition is not met? The answer is: it depends. After installing Code Contracts, project properties displays a new tab at the bottom named “Code Contracts” where you can tweak the contracts behavior for each of the build configurations that you have defined (Debug, Release, etc…).

Let’s concentrate on Runtime Checking for now: after you have checked it, you can decide which kind of contracts to enable; you should refer to official documentation for a complete explanation of all the options. For now, let’s just pick “Full” and check “Assert on contract failures”. With this choice, pre and postconditions will be tested at runtime and if any of them is not met a dialog will be shown detailing the failing condition.

So, let’s try calling the Invert method with a null string and let’s see what happens. Add the following code to the class above, compile and run.

[sourcecode language="csharp"]
public static void Main()
{
Console.WriteLine(Invert(null));
}
[/sourcecode]

This is what you should see:

As you can see, this looks exactly like using Debug.Assert calls from System.Diagnostics (many of us, myself included, used debug asserts in place of preconditions). In reality, contracts are much more powerful since

• you can not just enforce preconditions but also guarantee postconditions and other class invariants
• contracts knows about class hierarchies: you can define contracts on interfaces and base classes and they will be inherited from derived classes
• it’s possible to analyse compliance to contracts in a static way, even without running the code!

We’ll discuss about all this in the next post. Stay tuned!

Next post in the series: Code Contracts: Invariants.