Design by Contract vs. Defensive programming

看了一些Design by Contract的资料，不太理解它和Defensive programming的区别。我自己的工作经验都是基于C programming，我编制的程序大部分都是基于defensive programming的方式，写一个函数，要做好多参数检查。写一个逻辑也要做很多异常的判定，是不是Design by Contract就可以省了这些麻烦事呢？

看了一些其他人的观点，我觉得除非语言本身支持，否则可能还是隐形的defensive programming。

摘记一下一些观点。


“Even if Design by Contract is a trademark (Eiffel Software, 2007) the idea behind it is the more general one of “defensive programming”. As software developers, we often concentrate our efforts in the main code of the application, which is the interesting part, and that provides the realization of the use cases identified during the early phases of the project.
......
The idea behind defensive programming is that you should not trust what comes from outside your code, even if it is your own code that calls other pieces of your own code; you could just as well call it “limited applied paranoia”. This is important not only for stability purposes (you do not want to call methods on a null pointer) but also for security; take for example the well known “SQL injection attacks” that happen when you trust too much the inputs of your users… a little verification helps to avoid disasters.”

Mark
"I fully agree. Even if unit testing is done with 100% coverage the key is that unit testing treats each object as a black box. A lot of defensive coding is implementation specific and potentially runtime specific.

Unit tests are exercised in a controlled environment and do not necessarily cover every possible situation that will be encountered at runtime. Defensive coding often catches a problem and pinpoints it. This eventually saves a lot of debugging time trying to trace where and why a particular attribute of an object is null or not within an expected range etc...

Many times I have been very thankful to Jeff and Paul for introducing me to defensive programming. It is easy to make assumptions about a runtime environment and simply ignore possible exceptions to the rules. By placing defensive code at key locations in methods most if not all of 'unanticipated' scenerios are caught prior to release. Things which are missed and fail after release are extremely easy to locate, understand, and fix.

Last point, placing defensive code within a method is far easier than writing a unit test for the method to catch many situations. It requires less effort and is far less likely to get out of synch since it is directly inside the method and directly related to the implementation."

"This is why I prefer . I tend to think of defensive programming as an internal design by contract. If I write my preconditions and postconditions into the method itself, and document that breaking the preconditions will result in exceptions, then I can write my code expecting failure. If there's a subtle problem that could arise in the code, then I'll write the test for it inside the method and document it so it doesn't break my flow. Then, after I'm pretty certain that I have all the state I need and there's no possible way the method could fail, I'll write the success case. It shouldn't be possible to ever fail a unit test in the first place. (And if it does, I have the code heavily logged so I can track down where it broke down and what the state was.)"


"Defensive programming is all about the supplier making sure that their code works when parameters passed in might not be what it expected. And also that the client passes in correct information. So in effect the code is validated on both sides. The immediate advantage of this technique is that is will severely reduce the number of bugs since the chances of incorrect information both passed in and validated are slim. The disadvantage of this is longer CPU time and execution. The computer simply needs to parse and run more lines of code. Not so much a problem in todays world where hardware is getting faster and cheaper, but years ago it might have caused people to stop and think. Defensive Programming is generally used when you do not know exactly how your function call will be executed, ensuring nothing bad will happen.
....................
Design By Contract is different in that the supplier and client know what each is doing, or at least doing what they say they are doing and trusting them to perform that role. The class may say that it validates all country codes to ensure 2 character ISO 3166-1 standards and that the client does not need to, for example, so the client will be able to pass in any value and know that the validation it outside of its scope. Again the pros and cons are immediately noticeable in that it saves processing time, but at the expense that there might possible be bugs and possible security issues."

甚至Embedded.com上把Design by Contract作为defensive programming strategy之一。