This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Soft Skills and have John Sonmez on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes How much do you say about defensive programming? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "How much do you say about defensive programming?" Watch "How much do you say about defensive programming?" New topic
Author

How much do you say about defensive programming?

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40034
    
  28
I have been discussing defensive programming here. How much do you say about defensive programming in the book?
Ludwin Barbin
Author
Ranch Hand

Joined: Jul 29, 2009
Posts: 30
    
    5
In my book, I mentioned defensive programming in light of Design by Contract (DbC).

Design by Contract (DbC)

The notion of contract relates to obligations and benefits. An obligation to one party (supplier) is a benefit to another party (client).

In programming, contract is translated to precondition and postcondition.

Precondition > Process > Postcondition

The following can be observed from DbC:
- the stronger the precondition, more work for the client
- the stronger the postcondition, more work for the supplier

The following assumptions can be made when error occurs,
- Error in runtime is an indication of a bug
- A precondition error is a bug in the client
- A postcondition error is a bug in the supplier

The benefits of DbC is that there is less programming involved – you get more, you check less. There is less redundancy and there is clear separation of responsibility. Both client and supplier knows exactly their boundaries. DbC also contributes to software reliability and testability. It also results to clear documentation and easy debugging.

As opposed to defensive programming, you always check for precondition, you always validate inputs anywhere they appear. You’re checking things blindly just in case. This style leads to a lot of redundancy and code bloat. Everyone is responsible yet no one accepts responsibility.


-- Ludwin Barbin
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40034
    
  28
Thank you.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How much do you say about defensive programming?