悠悠的专栏

     对象真正的威力并不在于继承，而是来自封装行为。     不能将模式作为一个单独的东西使用，应该把它们结合起来。模式应该相互配合，共同解决问题。     功能分解方法的挑战：能者多责； 难题：应对变化。     对于阻止变化，我们无计可施。但是我们对变化本身却并非无能为力。     虽然无法预测会发生什么变化，但是通常可以预期哪里会发生变化。面向对象的巨大优点之一，就是可以

设计模式回顾    面向对象原则的总结：    1、对象是具有明确定义的责任的事物；    2、对象对自己负责；    3、封装指的是任何形式的隐藏：    （1）数据隐藏    （2）实现隐藏     （3） 类隐藏     （4）设计隐藏     （5）实例化隐藏    4、使用共性和可变性分析抽象出行为和数据中的变化；    5、按接口设计    6、将继承看成一种将变化概念化的方法，而不是

Singleton 模式    Singleton 模式和 Double－Checked Locking 模式都可以用于确保某个类只有一个对象实例化。两个模式的区别在于：Singleton 模式用在单线程应用程序中，而 Double－Checked Locking 模式用于多线程应用程序。关键特征：    意图：希望对象只有一个实例，但没有控制对象实例化的全局对象。还希望确保所有实例使

Object Pool 模式关键特征：    意图：在创建对象比较昂贵，或者对于特定类型能够创建的对象数目有限制时，管理对象的重用。    问题：对象的创建和管理必须遵循一组定义明确的规则集。通常这些规则都与如何创建对象、能够创建多少个对象和在已有对象完成当前任务时如何重用它们等等相关。    解决方案：在需要一个 Reusable 对象时，Client 调用 ReusablePo

    如果要遵循模式的原则和实践，就暗含着必须将对象的使用与对象的构造和管理分开来，各种工厂模式应运而生。    软件开发的大背景：    规则：先考虑系统中需要什么，然后再去关注如何创建系统......也就是说，我们应该在确定了对象是什么之后再定义工厂。首先，确定对象是什么，它们如何工作，然后确定如何对其实例化。    对象应该要么构造、或管理其他对象，要么使用其他对象，而不应该兼

Observer 模式关键特征：    意图：在对象之间定义一种一对多的依赖关系，这样当一个对象的状态改变时，所有的依赖者都将得到通知并自动更新。    问题：当某个事件发生时，需要向一系列变化着的对象发出通知。    解决方案：Observer 将监视某个事件的责任委托给中心对象 Subject。    参与者与协作者：Subject 知道自己的 Observer，因为 Ob

Decorator 模式    Decorator 模式的工作原理：可以创建始于 Decorator 对象（复杂新功能的对象）终于原对象的一个对象“链”。    每条链都始于一个 Component（ConcreteComponent 或 Decorator）。每个 Decorator 对象后面都跟着另一个 Decorator 对象或原 ConcreteComponent 对象。对象链总是

    开闭原则：模块、方法和类应该对扩展开放，对修改封闭。也就是说，应该将软件设计得不对其修改就能扩展功能。 开闭原则本质上意味着将软件设计成为新功能能够作为单独的模块加入系统，这样就尽量降低了集成成本。    完全遵守开闭原则几乎是不可能的，但是它可以作为一个目标，指引正确的方向。代码越遵守这一原则，以后适应新（而且可能是无法预测的）需求就越轻松。    依赖倒置原则：    1、

    设计常常被认为是一种合成过程，一种将事物放在一起的过程，一种组合过程。按照这种观点，整体是由部分组合而成的。先有部分，然后才有整体的形式。    但是，只是把预先形成的部分加起来，不可能形成有自然特征的任何东西，从部分构造整体，不可能得到优美的设计。    优秀的设计要求胸中始终有丘壑。    每个部分都因其存在与更大整体的背景中而被赋予了特定的形式。    这是一个分化的

    当人们开始学习设计模式时，他们经常把注意力放在模式提供的解决方案上。这看起来似乎很合理，因为设计模式被广为宣传的一点就是能够为实际问题提供优秀的解决方案。    但是，这从方向上来说就是错误的。在尝试将某个解决方案应用到一个问题之前，应该先理解问题。这种只是寻找在何处应用模式的方法，只能告诉你要做什么，但是不能告诉你什么时候或者为什么使用。     将注意力放在模式的上下文——模式

Strategy 模式    定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换。Strategy 模式使算法可独立于使用它的客户而变化。    基础原则：    1、对象都具有职责；    2、这些职责不同的具体实现是通过多态的使用完成的；    3、概念上相同的算法具有多个不同的实现，需要进行管理。    将问题域中的各个行为互相分离开来——也就是说将它们解耦

    短期的抄近路，可能会在长期导致问题严重复杂化。灾难往往是由短期未臻最优的决策，长期积累而引起的。许多项目只关心处理眼前的紧迫需求，却不顾将来的维护。    1、针对接口进行编程，而不要针对实现编程；    2、优先使用对象组合，而不是类继承；    3、考虑设计中什么应该是可以变化的。这种方法与关注引起重新设计的原因刚好相反。它不是考虑什么会迫使设计发生改变，而是考虑什么能够在

对象    传统看法：具有方法的数据（从实现的视角来看待对象，太简单，太肤浅了）；    新看法：具有责任的实体。这些责任定义了对象的行为（从概念视角出发）。    关注动机而非实现，使设计模式中反复出现的主题，因为将实现隐藏在接口之后，实际上是将对象的实现与使用它们的对象解耦了。封装    封装不仅仅是数据隐藏；封装应该被视为“任何形式的隐藏”，可以是隐藏数据，但还可以隐藏实

Facade 模式    为子系统中的一组接口提供一个统一接口，Facade 模式定义了一个更高层的接口，使子系统更加容易使用。关键特征：    意图：希望简化原有系统的使用方式，需要定义自己的接口。    问题：只需要使用某个复杂系统的子集，或者，需要以一阵特殊的方式与系统交互。    解决方案：Facade 为原有系统的客户提供了一个新的接口。    参与者与协作者：为

Adapter 模式    将一个类的接口转换成为客户希望的另一个接口。Adapter 模式使原本由于接口不兼容而不能一起工作的类可以一起工作。关键特征：    意图：使控制范围之外的一个原有对象与某个接口匹配。    问题：系统的数据和行为都正确，但接口不符。通常用于必须从抽象类派生时。    解决方案：Adapter 模式提供了具有所需接口的包装类。    参与者与协作

Factory Method 模式关键特征：    意图：定义一个用于创建对象的接口，让子类决定实例哪一个类。将实例化推迟到子类。    问题： 一个类需要实例化另一个类的派生类，但不知道是哪一个。Factory Method 允许派生类进行决策。    解决方案：派生类对实例化哪个类和如何实例化做出决策。    参与者与协作者：Product 是工厂方法所创建的对象类型的接口