File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
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 EJB 3 in Action this week in the EJB and other Java EE Technologies 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: 36478
    
  16
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: 36478
    
  16
Thank you.
 
 
subject: How much do you say about defensive programming?
 
Similar Threads
Would you consider them Singletons?
curly braces and comments
Runtime.exec("c.bat")
Defensive programming... or not
Tic-tac-toe Design