设计模式序

1. 功能分解是一种处理复杂问题的自然方法
   1. 这种方法就称为“功能分解”，因为分析人员将问题分解成了多个功能步骤（这些步骤就构成了这个问题）。你我都会这样做，因为解决更小的问题，比解决整个问题更简单
   2. 问题
      1. 功能分解方法的一个问题在于，它通常会导致让一个“主”程序负责控制子程序，这是将功能分解为多个子功能的自然结果。
         1. 用委托来解决“：

                                        但是，主程序所承受的责任太多了：要确保一切正确工作，还要协调各函数并控制它们的先后顺序，因此经常会产生非常复杂的代码。如果让一些子函数负责自己的行为，而且能够告知主函数执行某些任务，并信任它知道如何执行，这种方式比功能分解的方式要容易得多。叱咤疆场的将军们和家庭中成功的父母对这种经验都了然于胸。现在，程序员也学会了，这就是所谓委托（delegation）

1. 1. 1. 能分解方法的另一个问题在于，它在为未来可能出现的变化未雨绸缪方面，在对代码合适地改进方面，都于事无补。变化是无法避免的，经常是因为要为已有的主题增加新的变体。例如，我可能不得不处理新的形状，或者需要显示形状的新方法。如果将实现各步骤的所有逻辑代码都放在一个大函数或大模块中的话，那么这些步骤的任何实质性变化，都必须对这个函数或模块进行修改。而且变化还会为隐错（bug）和意料之外的结果创造机会
2. 怎么理解对象：

            理解对象的最佳方式，是将其看成“具有责任的东西”

1.  使用Fowler视角观察对象：
   1. 在概念层次上，对象是一组责任。
   2. 在规约层次上，对象是一组可以被其他对象或对象自己调用的方法（也称行为）。
   3. 在实现层次上，对象是代码和数据，以及它们之间的计算交互
2. 抽象类可以充当其他类的占位符

抽象类可以充当其他类的占位符。可以使用抽象类定义其派生类必须实现的方法。抽象类还可以包含所有派生类都能够使用的公共方法。派生类是使用抽象类的默认行为还是使用自己的有所变化的行为，由派生类自己决定（这与“对象自己负责自己”的要求一致）

1. 抽象类不只是不能实例化抽象类经常被描述为“不能实例化的类”。
   1. 这个定义本身没错——在实现层次上。但是局限性太大了。在概念层次上定义抽象类会更有帮助。在概念层次，抽象类就是（实现抽象类所代表的概念的）其他类的占位符。
   2. 也就是说，抽象类为我们提供了一种方法，能够给一组相关的类赋予一个名字。这使我们能够将这一组相关类看成一个概念。
   3. 在面向对象范型中，必须总是从概念、规约和实现所有三个视角层次来思考问题