《设计模式解析》笔记

许多bug都源于代码修改。


需求总在变化。


软件开发的目标：高内聚，低耦合


软件开发过程中的视角：
概念：职责“软件要负责什么”
规约：函数或方法“怎么使用软件”
实现：代码和数据“软件怎样履行自己的责任”


面向对象范型以对象概念为中心。
对象是通过寻找在问题领域中的实体而被发现的。然后再通过查看这些实体需要做些什么，为每个对象确定责任（或者称方法）。
对象是具有责任的东西，自己负责自己，清楚地定义责任。


隐藏实现（即封装它们）有助于松耦合。


设计模式源自建筑学和人类学。


学习设计模式的理由：
复用解决方案
确立通用术语
模式还提供更高层次的视角，避免“过早处理细节”


Facade模式简化了对所需子系统的使用过程。但是，由于Facade并不完整，因此客户可能无法使用某些功能。


Adapter模式将一个类的接口转换为客户希望的另外一个接口，使原本由于接口不兼容而不能一起工作的类可以一起工作。
Adapter模式最常见的用途就是保持多态性。
两种类型：
对象Adapter模式：对象包含另一个对象
类Adapter模式：多继承


Facade模式简化了接口，而Adapter模式则将一个已有的接口转换成另一个接口。


封装应该被视为“任何形式的隐藏”。


类型的封装是通过多态使用具有派生类的抽象类（或者具有多种实现的接口）实现的。


发现变化并将其封装。


针对接口编程，而不要针对实现编程。
优先使用对象组合，而不是类继承。
考虑设计中什么应该是可变的，考虑能够在不引起重新设计的前提下改变。（对变化的概念进行封装）


Strategy模式对算法的选择和算法的实现相分离。让使用算法的类包含一个抽象类，该抽象类有一个抽象方法指定如何调用算法。每个派生类按需要实现算法。


Bridge模式的意图：将抽象与其实现解耦，是它们都可以独立地变化。
将一组实现与另一组使用它们的对象分离。Abstraction为实现的对象定义接口，Implementor为具体的实现类定义接口。Abstraction的派生类使用Implementor的派生类，却无需知道自己具体使用哪一个ConcreteImplementor。


工厂模式（具体产品类派生自或实现了抽象产品类）
简单工厂模式：工厂类new具体产品类。
工厂方法模式：创建抽象工厂类，具体工厂类new具体产品类。
抽象工厂模式：创建抽象工厂类，具体工厂类new具体的产品族。


先考虑系统中需要什么，然后再去关注如何创建系统。


开发可分为以下两步：
1.定义对象和它们的协作方式。
2.编写为相应情况实例化对象并在对象共享时管理已有对象的工厂。（工厂）


工厂能够提高内聚性，松散耦合，并有助于测试。


对象应该要么构造和/或管理其他对象，要么使用对象，而不应该兼而有之。


Singleton模式用在单线程应用程序中，Double-Checked Locking模式用于多线程应用程序。


Object Pool模式：
在创建对象比较昂贵，或者对于特定类型能够创建的对象数目有限制时，管理对象的重用。


开-闭原则：
用面向对象的语言来讲，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。
解决问题的关键在在于抽象化。


可以使用共性与可变性分析（CVA）找到系统中的变化。
开发人员需要一种方式，首先弄清有些什么东西，然后再尝试找到它们之间的关系。
首先，使用CVA找到问题域中存在的各种概念（共性）和具体的实现（可变性）。然后，继续为封装这些概念的抽象制定接口。接着考虑你将如何使用从该抽象派生的具体实现，根据这一点派生接口。


Decorator模式动态地给一个对象添加一些额外的职责。可以无需创建子类，而扩展一个对象的功能。


模式的分类：
创建型：创建或实例化对象 Abstract Factory模式、Singleton模式、Double-Checked Locking模式、Factory Method模式
结构型：将已有的对象组合起来 Facade模式、Adapter模式、Bridge模式
行为型：给出一种提供灵活（变化）行为的方式 Strategy模式


Observer模式：
在对象之间定义一种一对多的依赖关系，这样当一个对象的状态改变时，所有依赖者都将得到通知并自动更新。依赖者实现同一个接口Observer。
Subject知道自己的Observer，因为Observer要向它注册（attach）。Subject必须在所监视的事件发生时通知Observer。


Template Method模式是一个旨在帮助我们在抽象层次从一组不同的步骤中概括出一个通用过程的模式。定义一个操作中算法的骨架，而将一些步骤延迟到子类中。不改变算法的结构而重定义它的步骤。