程序员修炼之道---从小工到专家（第5章）

弯曲，或折断

26，解藕与德墨忒尔法则demeter

把你的代码组织成最小组织单位，并限制他们之间的交互。

使耦合减至最少：

你需要直接使用某个功能，不需要拿到某个类再处理。应该让某个类给你提供封装。

函数的德墨忒尔法则：

使模块之间的耦合减至最少。

这真的有关系吗？：

函数的德墨忒尔法则规定，某个对象的任何方法都应该只调用属于以下情形的方法：

      它自身，传入该方法的任何参数，它创建的任何对象，任何直接持有的组建对象。

反例：全局函数，传入后再处理得到的对象。

这可以让你的代码适应性更好，更健壮，代价就是需要封装。有时候你会反规范化来获得更大的性能提升。

大型项目还需要物理解藕，文件、目录及库，可以参考Large-Scale C++ Software Design

27,元程序设计

细节会弄乱我们的代码，特别是它们经常变化的话。

动态配置：

要配置，不要集成。

不光文本，颜色可以配置，甚至中间件，算法，数据库，用户风格界面等都可以。

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

元数据：关于数据的数据，如描述   schecma的文件。

在典型情况下，元数据在运行时被访问和使用。

元数据驱动的应用：

还可以规定动作，不只是设置。这样可以把具体情况放在编译的代码外部。

将抽象放进代码，细节放进元数据。

带来的好处：

     它迫使你接触你设计的耦合，从而带来更灵活、可适应性更好的程序。

     它迫使你通过推迟细节处理，创建更健壮、抽象的设计。

     无需重新编译应用，就可以对其定制。可以利用这个，修改正在运行的产品的bug。

     可以通过一种大为接近问题领域的方式表示元数据。

     可以用相同的应用引擎，修改元数据来得到新的项目。

     可以提高“可撤销性”

商业逻辑：

    你可以选择在程序启动时读取并应用元数据，更好的是在运行时读取并应用。这样就不要重启啦。

协作式配置：

动态根据应用或者组件，让你的程序动态适应。

不要编写渡渡鸟代码：

没有元数据，你的程序可能无法获得它应有的适应性与灵活性。你一直改啊改。

28，时间耦合

时间：并发和次序。

设计时很少考虑，多是先这个，再那个。但是这会带来时间耦合。

我们需要容许并发，并考虑接触任何时间或次序上的依赖。工作流分析、架构、设计、还有部署。

工作流：

UML活动图来捕捉他们对工作流的描述。

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

分析工作流，以改善并发性。

架构：

饥饿的消费者模型：用一些独立的消费者任务和一个集中式工作队列取代中央调度器。各个消费者任务从工作队列中抓取一项，并对其处理。当各个任务完成其工作后，就回到队列中抓取下一项。这样，每个组件都在时间上解除了与其他组件的耦合。

用服务进行设计。

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

为并发进行设计：

多线程，遵守约束，这将帮助解除代码的耦合，并与靠巧合编程作斗争。

编写线性代码，我们很容易做出一些假定，把我们引向不整洁的编程。并发会迫使你更仔细的思考。

     必须对任何全局或静态变量加以保护，使其免于并发访问。

     如调用前如何确保对象有效。当然不是靠巧合，可以借助类不变项？

更整洁的接口：

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

考虑线程安全，考虑调用时序。

总是为并发进行设计。

部署：

并发程序方便部署。灵活地选择部署方式。

29，它只是视图

分而治之：模块（类）都有自己的责任。它具有单一的、定义良好的责任。

将模块划分后，显然需要一种整洁、灵活的方式来进行交互。

发布/订阅：

对象对需要的事件，发布者有事件时给每个订阅者发送事件。－>可以带来模型与模型的视图的分离。

MVC：

每个视图都有自己的控制器

既让模型与表示模型的GUI分离，也让模型与管理视图的控件分离。

使视图与模型分离。这也会提高可撤销性。

Java树视图

超越GUI

MVC未必一定要跟图形化有关。控制器是一种协调机制，不需要跟输入设备有关。

     模型。表示目标对象的抽象数据模型。模型对任何视图或控制器都没有直接的了解。

     视图。解释模型的方式。它订阅模型中的变化和来自控制器的逻辑时间。

     控制器。控制视图、并向模型提供新数据的途径。它既向模型也向视图发布事件。

仍然有耦合

     他们之间人有一些了解，接下来需要发布和订阅都不需要互相了解，也无需互相直接调用。

30，黑板

黑板实现：

用黑板协调工作流。说实话，没看懂。