21.按合约设计

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了21.按合约设计相关的知识,希望对你有一定的参考价值。

日常中,人与人打交道存在权利与责任,以及信任的问题,这些问题会让人与人之间的交往变得困难,那么为了解决这些困扰,在人与人打交道时会用合约的方式来明确下双方的权利责任。

DBC

软件设计中为了确保软件模块的权利与责任,以确保程序的正确性,也引入了合约的概念,这就是DBC(Design By Contract)按合约设计。

什么是正确的程序?程序只做它声明中要做的事情,不多做也不少做。

DBC的方式:用文档记载并约定软件模块的权利和责任,以确保程序正确性。用文档记载这样的声明,并进行校验,是按合约设计(DBC)的核心所在。

DBC的流程:

     1.前条件:为了调用例程,必须为真的条件

     2.后条件:例程保证会做的事情

     3.类不变项:类确保从调用者的视角来看,该条件总是为真

*如果调用者满足了例程的所有前条件,例程应该保证在其完成时,所有后条件和不变项将为真。

(java中的DBC工具是iContract,书中的例子代码是以iContract写的)

对在开始之前接受的东西要严格,而允诺返回的东西要尽可能少。记住,如果你的合约表明你将接受任何东西,并允诺返回整个世界,那你就有大量代码要写了!

面向对象的继承和多态是合约发挥作用的领域之一。

实现DBC

   1.断言

    支持断言式编程的语言可以通过断言部分实现DBC。

    为什么是部分实现?因为:

      首先,断言不支持继承层次向下遗传

      其次,断言不支持“老”值。(什么是“老”值?)

      最后,runtime和库的设计不支持合约(什么意思?)

  2.语言支持

    有些语言内建对DBC的支持(Eiffel和Sather)

    C,C++的有些预处理器能处理作为特殊注释嵌入在代码中的DBC。预处理器可以把这些注释展开为断言代码(Nana)

    Java可以使用iContract

DBC与早崩溃

  谁负责检查前条件,调用者?还是被调用的例程?如果是作为语言的一部分实现的,答案是两者都不是。前条件是在调用者调用例程之后,但在进入例程之前,在幕后测试的。因而如果要对参数进行任何显式的检查,就必须由调用者来完成。因为例程永远也不会看到违反了前条件的参数。

  通过早崩溃、在问题现场找到和诊断问题要容易的多。

不变项的其他用法

  1.循环不变项

    循环不变项是对循环最终目标的描述,有时在复杂的循环上设置正确的边界条件会很成问题。循环常有的“香蕉”问题、“篱笆桩”问题、“差一个”问题。这样在循环每次执行前以及迭代时它都是有效的。

  2.语义不变项

    语义不变项描述的是一种不可违法的需求。固定的需求或不可违反的法则,和一些需求中细化出的政策是要加以区分的。细化的政策是可以动态的变化的。而需求中的一些基本定义是不变的。那么用语义不变项去清晰、简介的定义出那些政策无论怎么变化都不会改变的基本法则。

动态合约与代理

  在“自治代理”的领域中。按照自治的定义,代理有权拒绝它们不想接受的请求。“能够互相磋商合约,以实现某个目标”的组件和代理是解决软件生产率危机的方法。

以上是关于21.按合约设计的主要内容,如果未能解决你的问题,请参考以下文章

EOS博彩合约设计

带有 OpenZeppelin 合约的 Tron 网络

EOS合约开发集中博彩游戏合约设计_bedrock_stable

EOS合约开发集中博彩游戏合约设计_bedrock_stable

EOS合约开发集中博彩游戏合约设计_bedrock_stable

基于智能合约的银行借贷方案设计与实现