读书笔记：程序员修炼之道-05-弯曲，或折断

弯曲，或折断

如何做出可撤销决策：

• 解耦与得墨忒耳法则 怎样让分离的概念保持分离，并降低耦合
• 元程序设计 怎样把各种细节代码完全移出代码
• 时间耦合
• 它只是视图 解除模型和视图的耦合

解耦和得墨忒耳法则

使耦合减至最少

对象之间直接的横贯关系可能很快的带来依赖关系的组合爆炸。

现象：

• 这样的C或者C++项目：用于连接某个单元测试命令比测试程序本身还要长
• 对某个模块的简单改动会传遍系统中的一些无关的模块
• 开发者害怕改动代码，因为他们不清楚哪些代码可能会受影响。

有许多不必要的依赖关系的系统非常难以维护，往往高度的不稳定，为了使依赖减少到最少，我们将使用得墨忒耳法则设计我们的方法和函数

函数的得墨忒耳法则

他设法阻止你为了获得第三个对象的方法的访问而进入某个对象。

得墨忒耳法则规定，某个对象的任何方法都应该只调用以下情形的方法：

1. 它自身
2. 传入该方法的任何参数
3. 他创建的任何对象
4. 任何直接持有的组件对象

该法则缩小了调用类中的相应集的规模。它能够让你的代码适应性更好，更加健壮。

存在的问题：

在实践中 你会发现你会写大量的包装方法，他们只是把你的请求转发给委托者，这些包装方法即会带来运行的代价，也会带来空间开销。

元程序设计

再多的天才也无法胜过对细节的专注

​ ——Levy’s Eighth Law

细节会弄乱我们整洁的代码——特别是们经常发生变化。

动态配置

要用元数据metadata描述应用的配置选项：调协参数，用户偏好，安装目录等等。

metadata ：严格来说是：元数据是关于数据的数据。常见的例子是：数据库schema或数据字典。广泛意义上：是任何对应用进行描述的数据。

元数据驱动的应用

目标：以声明的方式思考（规定做什么，而不是怎么做）并创建高度灵活和可适应的程序

方法：以一般情况编写程序，而把具体情况放在别处——在编译的代码库外。

好处：

• 它迫使你解除你设计的耦合，从而带来更加灵活，可适应性更好的程序。
• 它迫使你通过推辞细节的实现，创建更加壮健，更抽象的设计。
• 无需重新编译应用，你就可以对其进行定制。
• 与通用的的编程语言相比，可以通过一种大为接近问题领域的方式便是元数据。
• 你甚至可以用相同的应用引擎，但是用不同的元数据 实现若干不同的项目。

商业逻辑

一个例子

不要编写渡渡鸟代码

没有元数据你的代码不可能获得她应有的适应性与灵活性。

时间耦合

谈论的忽视的方面：

并发（事情在同一时间发生）和次序（事情在时间中的相对位置）

我们需要容许并发，并考虑解除任何时间或者次序上的依赖。

工作流

活动图：由一组绘制成圆角方框的动作组成。离开某个动作的箭头或者去往另外一个动作。或者去往叫做同步条的粗线。

你可以使用动作图，通过找出本可以，但却没有并行执行的操作的动作，使并行度最大化。

架构

实际上我们创建的不是组件而是服务——位于定义良好的 一致的接口之后的独立，并行的对象。

为并行进行设计

多线程编程施加了某些设计约束。这些约束将帮助我们解除代码的耦合。

更加整洁的接口

对于并发的时序依赖进行思考能够引导你设计更整洁的接口。

部署

设计具有并发要素的架构，对许多并发服务的处理进行思考就会变得更加容易：模型变得普遍。

它只是视图

事件：一个事件就是一条特殊的消息，说明刚刚发生的一件事情。我们可以利用事件将某个对象的状态变化通知给可能感兴趣的其他对象。

发布/订阅

使用发布订阅机制实现一种设计概念：模型和模型的视图分离。

Model-View-Controller

既让模型和表示模型的视图分离，也让模型和管理视图的控件分离。参考SpringMVC的实现

Java树视图

在Java的树widget中可以找到MVC设计的一个好例子。树widget实际上是按照MVC模式组织的一组不同的类。

超越GUI

• 模型：表示目标对象的抽象数据模型。模型对任何视图或控制器都没有直接的了解
• 视图：解释模型的方式。它订阅模型中变化和来自控制器的逻辑事件。
• 控制器：控制视图，并向模型提供新数据的途径，它既向模型，也向视图发布事件。

在高级系统之中，拥有调试视图，可能会很方便，增加一种设施，用于跟踪各个事件，也可以节省大量时间。

黑板

Use BlackBoards to Coordinate Workflow

用黑板协调工作流

我们可以用黑板协调完全不同的事实和因素，同时又使哥参与方保持独立，甚至隔离。