views:

106

answers:

4

I've been thinking about creating a Java framework that would allow programmers to specify invariants (pre- and post-conditions) on interfaces. The purpose would be to make code more robust and reduce the number of unit tests that would need to be written for different implementations of the same interface.

I envisage creating some way of annotating methods with invariants that the programmer would also write. E.G.

interface Sort {
    int [] sort(int [] nums);
}

would be decorated with an annotation to ensure that any implementations return a sorted list. This annotation would be linked to a unit test that could be run at compile time against any implementation.

Is this a crazy idea or would this be useful to the wider programming community?

+3  A: 

This sounds like it could be related to JML and ESC/Java, both of which have found reasonably wide-spread adoption within the kinds of projects that need a little more software quality than is offered by the usual set of techniques.

Gian
Thanks I will take a look at JML
Tarski
I've never heard of either. "Reasonably wide-spread adoption" - data, please. I'll bet you have no basis whatsoever for this statement, except for one or two projects that you've done.
duffymo
Gian
There you go again: "most" is just as ephemeral as your "wide-spread". Both of those citations are academic in nature. I've never once had the programming by contract idea come up in an interview or a professional engagement of any kind. I only heard about it in graduate classes. I think that's because the concept appeals to academics, but the adoption rate outside the academy is slow to non-existent.
duffymo
I'm not claiming that it's popular. I'm saying that among software engineers who have any knowledge of formal verification, JML is well-known. That was why I qualified my original statement with "within the kinds of projects that need a little more software quality than is offered by the usual set of techniques". And frankly, your ignorance is just as anecdotal as my experience. Making strong claims about its use based on the fact that you've never heard of it is pretty arrogant.
Gian
I don't know of any software projects that would say they don't need high quality. I learned Eiffel and DBC back in 1994, so I'm not unaware. I will admit that I don't know about JML - because none of the companies or engagements I've had since then have asked for it.
duffymo
Most software projects would like higher quality, but don't want to pay for it, so they use standard techniques like unit testing and many some kind of methodology involving code reviews, but they don't go for formal methods. JML is in the realm of formal methods. And it hardly surprises me that companies haven't asked for it... it seems like it would only be used in places where software professionals recommended it as the right tool to obtain something closer to a mathematical guarantee of correctness for critical code.
Gian
I can't think of software that's more critical than flight control. The government demands that it be written in ADA. Does ADA have DbC built in?
duffymo
You're appealing to a false syllogism there. You wouldn't write flight control software in Java because you cannot make strong enough guarantees about correctness (and timing constraints). Ada has various external mechanisms available for DbC, and adding contracts to the core language is on the to-do list (AI05-0145). That's by-the-by, however, as there are many formal methods available. Extended static checking with JML specs is towards the low-end, the kinds of stuff they do on Ada code for Avionics is at the high end, with proportional cost and time involved.
Gian
You might be interested in SPARK http://www.praxis-his.com/spark.aspx which is a subset of ADA used for formal verification.
Tarski
Not false - just trying to see if software that requires higher quality uses DbC. Wikipedia tells that ADA has a plug-in for it, but I don't know anyone who writes ADA so I can't confirm. I see that Spring Contract exists, but I don't know how widely it's used. I know a lot of people who use Spring, but no one who uses Spring Contract.
duffymo
I don't think whether DbC is widly adopted or not is the only indicator of whether it is a good methodology. I cant take this argument seriously without discussions of the merits of DbC verses Unit testing or TDD
Tarski
I think success in the marketplace is a very good indicator indeed. I think that DbC can be done without a framework. When I write classes, I check incoming parameters. Call that preconditions if you want. I don't need a framework to do it. Truth is, it's not either/or. People do both.
duffymo
Ideally DbC (or any other verification) should be done as static analysis at compile time. You get much stronger assurances and it doesn't introduce any runtime cost.
Gian
A: 

What great programming Idea is not crazy!!! I definitely think it would be useful.

StudiousJoseph
Agreed, but shouldn't this be a comment?
Willi
A: 

I think Bertrand Meyer's programming by contract idea is largely dead. He built pre- and post-conditions into Eiffel, but that language is below Latin on the usage scale.

There are Java programming by contract libraries out there; Contractor is one. But its day has come and gone. The fact is that even Eiffel had a way to turn them off in production, because the runtime cost wasn't worth the benefit.

Only 6 Eiffel questions on Stack Overflow - a small percentage indeed. If you search for SO tags with "contract" in them, you'll see a very small number. Not much interest in the topic on this site. It claims to draw the biggest audience of professional programmers in the world.

duffymo
interesting views. would you say that test driven development is a better approach than design by contract?
Tarski
"would you say that test driven development is a better approach than design by contract?" - absolutely. There's no runtime penalty; they provide better information about the behavior of classes; they document far better than contracts would. Given a choice, I'd rather have the tests.
duffymo
I wouldn't say they document far better than contracts would. Using TDD you might test a few inputs to stretch the functionality, but a contact may define in abstract terms what the function actually does. e.g. a sum(x, y) function might have contract returns x + y whereas a test might just assert that sum(1, 2) = 3
Tarski
I really have to disagree. There is still plenty of work going into various design-by-contract-based approaches to correctness, although the work has certainly moved on from Eiffel. TDD does not (and cannot!) make any claims towards ensuring correctness. Testing does not provide anything except reasonable suspicion of correctness. More rigorous approaches (such as those involving contracts) can make much stronger claims.
Gian
I suppose the trouble comes when you try to write contracts for a complex routine. People naturally prefer examples, like tests than a formal definition
Tarski
And fair enough too. I'm definitely a fan of testing, but there is a continuum stretching from doing no kind of validation whatsoever all the way to constructing your entire program inside a theorem prover, and testing falls somewhere below the kinds of design-by-contract techniques that we've been discussing. You go to the extra effort to provide more assurances on the correctness of your software when it is worth spending the time or money to do so.
Gian
+1  A: 

I think design by contract is a great idea and I've glanced at frameworks that provide that functionality in Java. I think what has held me back is that getting buy-in from a team for these sorts of frameworks can be difficult. I think it's perceived as being only of academic interest which is strange because really it's just like embedding unit tests within the code.

Java's main nod in this direction, the assert statement, has been around for several years but I rarely see it used - often only in the code I write myself! There's a lot of mileage in using asserts (especially combined with unit tests) and I've found a few bugs using them, it's just a pity people don't use them.

Cheers,

Ian.

Ian Fairman
I agree with you that asserts are underused. I've just done my SCJP exam and Sun recommends using asserts to check pre-conditions on private methods only. But really, there is nothing to stop you from using them to check post-conditions as well.The problem I have with assertions is that they are by default disabled - I would like to use a framework that does compile time checking.
Tarski