第21节 按合约设计
1、注重实效的程序员会不信任自己，所以他们针对自己的错误行为进行防卫性编码。
2、按合约设计（Design By Contract，简写DBC）是 Bertrand Meyer 为 Eiffel 语言发展的概念。它的核心是用文档记载模块的权利与责任，并进行校验。它的目的是对函数做一些前置检查和后置保证，结合编译器的支持，我们能够尽早的发现代码问题。
3、DBC 有三个概念。
前条件：为了调用例程必须为真的条件。
后条件：例程保证会做的事情，其完成时的状态。
类不变项：其确保从调用者的视角来看，该条件总是为真。
4、Java 中的 iContract 框架是专为 DBC 设计的，它通过注释里的 @pre、@post、@invariant 声明这三个概念。它会读取注释并生成包含断言逻辑的源文件。Eiffel 则是通过 require、ensure、is 三个值表示对应概念。但是支持 DBC 的语言真的很少。
第22节：死程序不说谎
1、对待程序我们通常会有“它不会发生”的心理状态，这会导致我们忽视一些问题。对于注重实效的程序员来说，如果我们忽略了一个错误，将是非常糟糕的事情。
2、我们一些异常情况，我们应该及早崩溃，用于强调问题的存在。
3、引起崩溃的时候不要造成破坏，比如申请的资源还没有释放等情况。
4、死程序带来的额危害通常比有隐患的程序要小得多。
第23节 断言式编程
1、如果它不可能发生，用断言确保它不会发生。
assert(string != NULL)
断言里写的为真的条件，当不为真时触发断言，程序退出。
2、断言检查的是决不应该发生的事情，而不是错误处理。
3、断言应该一直开着，不要在线上环境关掉它。
断言对应的是一种强提示，它迫使我们必须遵守。像是单元测试，我们通常都使用断言的形式进行检查。
第24节 何时使用异常
1、异常很少应作为程序的正常流程的一部分使用，异常应该保留给意外情况。如果移除了所有的异常处理器，代码就无法运行，那说明异常正在被用于非异常情况中。
2、是否应该使用异常取决于实际情况。比如打开文件，文件不存在，是否应该发生异常？如果文件应该在那里，那么异常就有正当理由。如果不确定文件是否在那里，返回错误就可以了。
第25节 怎样配平资源
1、对于资源（内存、事务、现成、文件、定时器等）的管理要有始有终，你分配了对应的资源，就需要考虑对应的解除逻辑。要有始有终。
2、嵌套的资源分配，应该使用与分配次序相反的顺序进行解除。
3、异常的配平需要避免违反 DRY 原则。例如文件打开的异常情况，会导致 try..catch 有两条路径，那如何避免在正常流程和 catch 流程都处理 error 情况呢？C++ 可以依赖对象自动析构的特性，Java 可以依赖 finally子句。
4、当无法配平资源时，需要设定一个规则，决定谁为某个聚集数据结构中的数据负责，以及如何负责。这里有点类似引用计数方案，无引用时释放。
5、自动化检查资源配平状态，可以依赖一些三方工具。
第26节 解耦与得墨忒（tei）耳法则
1、把你的代码组织成最小单位（模块），并限制他们之间的交互。如果随后必须替换某个模块，其他模块仍能够继续工作。
2、应使耦合减至最少。对象间直接的横贯关系，有可能很快带来依赖关系的组合爆炸。比如对某个模块的“简单”改动会传遍系统中的一些无关模块。
3、函数的得墨忒耳法则，它规定了某个对象的任何方式都应该只调用属于以下情形的方法：
- 它自身
- 传入该方法的任何参数
- 它创建的任何对象
- 任何直接持有的组件对象
4、得墨忒耳法则的好处是它使得代码的适用性更好，更健壮，但这也有一定的代价。如果某些解耦的操作很复杂，或者解耦带来某些时间和空间的重大开销，这时就需要根据实际情况考虑，可以暂时舍弃该法则。
第27节 元程序设计
1、元数据是关于数据的数据，即对应用进行描述的数据。典型情况，元数据在运行时，而不是编译时被访问和使用。
2、我们想要让我们的系统变得高度可配置，像是屏幕颜色，提示文本等，这些应该作为配置项而不是作为代码集成到项目中。
3、以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活的可适应的程序。结合元数据就是，将抽象放进代码，细节放进元数据。
4、Enterprise Java Beans 是一个用于简化分布式、基于事务的环境中的编程框架。它处理了不同机器、在不同数据库供应商之间，不同线程及复杂平衡的事务。它的使用只需我们编写一个 bean，并将其放到 bean container 中。
5、更好的协作式配置是让应用自身适应其环境，进行动态配置。
第28节 时间耦合
1、时间耦合就是关于时间的各种事项。
2、软件设计中，时间的角色通常有两方面对我们来说很重要：并发（事情同一时间发生）、次序（事情在时间中的相对位置）。我们期望的是要容许并发，并考虑解除任何时间次序上的依赖。
3、可以选择使用 UML 活动图进行工作流分析，以改善其并发性。
4、在设计架构时，用服务进行设计而不是组件。饥饿的消费者模型是在多个消费者进程间进行快速而粗糙的负载平衡的一种有效途径。
5、编写线性代码，我们很容易做出一些假定，把我们引向不整洁的编程。但并发会迫使你更仔细的对事情进行思考。
6、尽可能使用线程安全的类，开发时也应尽可能设计线程安全的类。
第29节 它只是视图
1、我们都知道应该将程序分而治之，划分成不同模块。这里模块（或类）的定义是，具有单一的定义良好的责任。那如何在不同模块之间进行通信，处理事件呢？有以下两种方式。
2、发布/订阅模式，又叫 Observer（观察者）模式。它的工作模式是，由订阅者 Subscriber 向发布者 Publisher 进行注册，注册之后，Publisher 的事件会通知到 Subscriber。未注册和解除注册将不会收到之后的事件通知。
3、Model-View-Controller 是一种将模型与表示模型的 GUI 分离的架构模型，它能有效降低数据和视图之间的相互影响。
第30节 黑板
1、设想侦探破案的过程，他借助于一块黑板，把不同线索写出来；其他侦探也可以写下自己的推断和已掌握的案情细节。所有这一切串联起来将共同帮助案件侦破，但不同的线索之间是可以独立进行的。
2、这里的黑板可以抽象为一种处理事件的模型。不同于原始的工作流需要考虑各种状况，不同组合，先后顺序等，黑板系统只管写入，读取，查询，通知等基础功能，任意符合条件的事件都可以进入这个系统。
3、黑板模型也是一种解耦形式。
标签：断言,小工,程序员,修炼,模块,配平,应该,异常,我们 From： https://www.cnblogs.com/fengjiale/p/17455718.html