Design By Contract (DBC) - is it any good?

[al0]

Hello,

I started to reconsider applicability of DBC in real applications and was somewhat stunned as I was unable to imagine any class hierarchy (or even worse interface and its implementations) to which some reasonable contract may be applied Moreover, I start to search an Internet for such examples and completely failed - there is a lot of articles but no one that I found contains such examples. May somebody point me to such examples and/or share his opinions/experience on/with DBC.

And other problem - I do not see any way to prove that contracts on subclasses are correct (preconditions are not stronger, and postconditions are not more relaxed then in parent).

Regards,

Oleksandr

[guznik]

Greetings,

I also was very confused when I first started designing an enterprise application about two years ago and I think I can give you some guidelines that have proven good practice:

* At first don't think in classes - think only in interfaces. If you need something that says "Hello World", draw an interface with a helloWorld() method and don't think about IO, DB or servlets - only about what the APPLICATIVE FUNCTIONALITY of the method is.

* Split your application horizontally and vertically, which means to technological layers and to applicative modules (I don't remember which is what) and then think about which square depends on which other square in the grid. This is where the actual CONTRACT comes in - if square A (for example "Say Hello Servlet") depends on square B ("Say Hello Service"), this means that the developer who is going to program the SayHelloServlet must know the interface you designed for SayHelloService but not its implementing class - the interfaces are the contracts between your layers/modules. If you didn't declare a dependence between two squares C and D, it means that the developer of C cannot use anything from square D.

* Use UML class diagrams and sequewnce diagrams. Class diagrams should contain all the interfaces and the dependencies between them (even though the actual dependence is between the implemented classes and not the interfaces, it proved to be the most clear way) so every developer knows his/her bounderies. Sequence diagrams help to understand the relationships between your interfaces. All your methods should appear in your sequence diagrams - if you don't find any reasonable place for a method in any sequence diagram - you probably don't really need this method.

* Unit tests - obviousely for development, but thinking about test cases for methods help in clearifying their purpose and can cause you to change the design (for example, if A.sayHello() should greet only nice people, when you think of the test cases "greet a nice person" and "greet a not-so-nice person" you may recall the the B.sayHi() method that also needs this chack and then you decide to write a new C.isNicePerson() method and make A and B dependent on C).
That's what I can think of right now. If you have more specific questions - please ask.

Gabriel

[al0]

Sorry, but all that you have written is more or less correct (there are some arguable points but not very significant), but has nothing to do with "design by contract".

Regards,
Oleksandr

Greetings,

I also was very confused when I first started designing an enterprise application about two years ago and I think I can give you some guidelines that have proven good practice:

* At first don't think in classes - think only in interfaces. If you need something that says "Hello World", draw an interface with a helloWorld() method and don't think about IO, DB or servlets - only about what the APPLICATIVE FUNCTIONALITY of the method is.

* Split your application horizontally and vertically, which means to technological layers and to applicative modules (I don't remember which is what) and then think about which square depends on which other square in the grid. This is where the actual CONTRACT comes in - if square A (for example "Say Hello Servlet") depends on square B ("Say Hello Service"), this means that the developer who is going to program the SayHelloServlet must know the interface you designed for SayHelloService but not its implementing class - the interfaces are the contracts between your layers/modules. If you didn't declare a dependence between two squares C and D, it means that the developer of C cannot use anything from square D.

* Use UML class diagrams and sequewnce diagrams. Class diagrams should contain all the interfaces and the dependencies between them (even though the actual dependence is between the implemented classes and not the interfaces, it proved to be the most clear way) so every developer knows his/her bounderies. Sequence diagrams help to understand the relationships between your interfaces. All your methods should appear in your sequence diagrams - if you don't find any reasonable place for a method in any sequence diagram - you probably don't really need this method.

* Unit tests - obviousely for development, but thinking about test cases for methods help in clearifying their purpose and can cause you to change the design (for example, if A.sayHello() should greet only nice people, when you think of the test cases "greet a nice person" and "greet a not-so-nice person" you may recall the the B.sayHi() method that also needs this chack and then you decide to write a new C.isNicePerson() method and make A and B dependent on C).
That's what I can think of right now. If you have more specific questions - please ask.

Gabriel

[al0]

So no one else is interested in Design by Contract?