在一份合同上单独写一句话（给你的程序也拟一份合同）

What is a correct program? One that does no more and no less than it claims to do.，下面我们就来聊聊关于在一份合同上单独写一句话?接下来我们就一起去了解一下吧!

在一份合同上单独写一句话

今天这一章叫Design by Contract（DBC）契约设计，我看了一半。说的是，在人类社会，我们会通过合同这种东西来规定双方的权利和义务，以及如果违反条款的后果。这一项机制也可以引入程序中。

What is a correct program? One that does no more and no less than it claims to do.

什么是一个正确的程序？一个不比它所声称要的多做或少做的程序。

Documenting and verifying that claim is the heart of Design by Contract (DBC, for short).

记录和验证这一声称，是契约设计（简称DBC）的核心。

每个方法都有做些事情，在它做这些事情的之前，他们会对当前的环境有所期待，最主要的期待就是输入参数。在它做完事情之后，也需要像它声称的那样，返回相应的数据。它的发明者把它们称为前置条件（Preconditions）与后置条件（Postconditions）。主要说说前置条件吧。作者特别举了一个例子来说明责任的归属。假如有一个除法方法divide()，那检查前置条件的认为是调用者还是divide()内部？答案是都不是，前置条件在他们中间，divide()默认所有参数都是正确的，所以验证的责任应该由调用者来承担。在传给divide()之前就完成检查。假如不小心把0传给了被除数，那可以抛异常、可以读取其他的数值，可以打印错误、可以直接结束程序……干什么都可以，但是不能把它传给divide()方法。在之前正交性那一章中作者提到，建议我们编写“害羞的（shy）”代码。只管好自己的事，手不要伸太长，不要与其他部分有过多的勾连。这一章契约设计强调的是要写“懒惰的（lazy）”代码，严格规定你想要接受什么，并尽可能少的承诺返回的内容。如果不对输入值做任何限制，并承诺会返回“整个世界”，那意味着你有一大堆代码要写。因为你要考虑所有情况，并作出相应的调整，否则就可能会出现一些意想不到的异常情况。比如，程序原本只能处理10位数字，但是调用者传入了11位数字，就可能造成结果错误，或者程序直接运行失败。边界往往是最容易出问题的地方，所以最好在一开始就规定清楚。就像常说的那句话“丑话说前面”，规矩在一开始就定好了，之后也可以有法可依。执行人可以更清晰明确地执行，执法者也可以名正言顺地进行处理。

字数：667

耗时：50分

··················END··················

,