partial design by contract with assertions

Question

I would like to get some opinions on an idea for a partial implementation of design by contract. The goal is to add to the languages that don't offer it a light version of contracts (invariants and post conditions only) without the need of an external library.

My example is written in Java but I suppose that the idea is good for a lot of OO languages.

We have a class like this:

class myClass{
    type1 field1;
    type2 field2;

    public myClass(type1 param1){
        //do something
    }

    public type3 method1(type1 param1, type3 param2){
        if (paramsAreNotOk()){
            throw new IllegalArgumentException();
        }
        // do a lot of things
        return //do something
    }
}

We extend the code above in this way:

class myClass{
    type1 field1;
    type2 field2;

    public myClass(type1 param1){
        //do something

        assert invariant();
    }

    public type3 method1(final type1 param1, final type3 param2){
        assert invariant();
        myClass old;
        assert ((old = this.clone()) != null)

        if (paramsAreNotOk()){
            throw new IllegalArgumentException();
        }
        //do a lot of things
        type3 res = //do something

        assert method1_post(old, param1, param2, res);
        assert invariant();
        return res;
    }

    protected boolean invariant(){
        // states something about myClass and return a boolean
        // OR
        // uses some assertions on some helping methods
    }

    protected boolean method1_post(myClass old, type1 param1, type3 param2, type3 res){
        // states something about res and about the modifications made on old
        // OR
        // uses some assertions on some helping methods
    }
}

Limitations of this approach:
- no pre-conditions.
- the contract is not inherited (but please note that invariant and post-conditions are protected and can be reused by a subclass).
- there isn't any check that invariant and post-conditions don't modify the state of our object, hence there is a risk of side effects.
- the contract is not part of our documentation in a clear way.
- we need to make cloneable every class.

Now, some questions:
- does this method hurt the performances in any way? I mean even the old and res local variables are removed by the JIT compiler if assertions are disabled?
- do you see any downside of this approach? Why wouldn't you use this in your classes?
- can you suggest any improvement?

Thank you for your reading and for your opinions.

Answer 1

It's not horrible, and in fact it's been written about by others before you. For instance, see Liskov/Guttag's Program Development in Java, which takes your approach to invariant checking, but calls it repOK() rather than invariant().

In a limited application, it kinda-sorta works. But there are a lot of problems that come out of the fact that contract specifications don't have to worry about the sort of "who's calling who" problems that real code does.

• Say you have some method F, which calls another method G. Imagine that F breaks the rep invariant while it runs, but fixes things before it returns. This is allowed, and in some cases required, but G doesn't know that, and it will incorrectly raise an exception.
• Constructors are worse. Say class D extends class C and overrides invariant(). D() calls C(), which calls D.invariant(), which is wrong. C does not have to satisfy D's invariant, which is stronger than its own.
• If a method is passed the wrong arguments by a client outside the class, then IllegalArgumentException is fine. But if the caller is inside the class, this is a regular old contract violation. You want to distinguish between the two. Gary Leavens talks about how JML does it in this paper, if you're interested.
• Postconditions expressed in terms of other class methods (that is, "postconditions") will cause infinite mutual recursion when checked.

My take is that DbC is interesting, and if the language has it (or, even better, something like Python's function decorators), or you have a tool like Modern Jass, then dig in. But doing it in pure Java isn't feasible. That said, I'm working on an invariant checking tool that generates code similar to what you have here, minus the call-chain issues (it works instead by extending the classes to accept a visitor which knows when it's proper to do the check). It requires Eclipse, and has problems of its own (mainly related bad words like private and static), but the checking mechanism is pure Java.

Answer 2

If you want "Design By Contract" for Java, you may want to take a look at how the (really) big guys are doing it! Here's Google's recent take on the subject with "Contracts for Java":

http://google-opensource.blogspot.com/2011/02/contracts-for-java.html

Now to answer two of your questions:

- do you see any downside of this approach? Why wouldn't you use this in your classes?

Because one downside is that it is highly verbose: so much verbose as to make the code barely readable.

- can you suggest any improvement?

Don't reinvent the wheel...

Answer 3

do you see any downside of this approach? Why wouldn't you use this in your classes?

Most Java classes I write are not clonable, because it's not easy to implement Clonable right in Java. Therefore I don't implement it when it's not absolutely necessary. I wouldn't want to have to do this just for your approach.