设计模式 - 读书笔记

程序设计七大原则：

1.单一职责原则

一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则。

2.开放封闭原则

一、开放封闭原则是面向对象所有原则的核心

二、1.对功能扩展开放 2.面向修改代码封闭

三、需求改变时，在不改变软件实体源代码（类、接口、方法等）的前提下，通过扩展功能，使其满足新的需求

总的来说：
一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

3.依赖倒置原则

1.高层模块不应该依赖于底层模块，两个都依赖于抽象类。

高层模块指的是调用者，底层模块就是指被调用者，或者框架。

2.抽象不应该依赖细节，细节应该依赖于抽象。我们要面向接口编程，而不是面向实现编程

3.依赖倒置原则的本质就是通过抽象 使各个类或者模块实现彼此独立，互不影响，实现模块之间的松耦合

总的来说：
抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

这个我感觉比较类似COM组件的开发，把一个抽象的类当成一个成体，对外暴露的是接口，而不是释放一个具体的对象给对方。

4.里氏替换原则：

1.子类可以替换父类

2.所有引用父类对象的地方，都可以使用其子类型代替

3.如果S是T的子类型，则T类型的对象可以替换为S类型的对象

总的来说：
所有引用基类（父类）的地方必须能透明地使用其子类的对象。在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

比如所有可以用QObject的地方，我都可以用QObject的子类去代替，不然继承就是有问题的。

5.接口分离原则：

1.客户端不应该依赖它不需要的接口

2.一个类对另一个类的依赖应该建立在最小接口上。

3.接口尽量细分，不要再一个接口中放很多方法。

总的来说：
使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。

6.迪米特原则： 设计类的原则

1.它要求一个对象应该对其他对象有最少的了解（最好只用一些接口或者方法去操作，让类本身去对状态等属性进行保存）

2.降低类之间的耦合

3.这是一个对类创建相关的原则和法则

总的来说：
一个软件实体应当尽可能少地与其他实体发生相互作用。
应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
也就是说尽量引入一个观察者模式，做SignalCenter

在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

7.合成复用原则：

1.尽量使用对象组合，而不是继承来达到复用。

可能会有些父类的方法，新生成的子类可能用不到，这个时候就有可能会导致一些问题

继承会出现三个问题：

1.破坏了系统的封装性，基类发生改变，子类的实现也可能会发生改变

2.子类如果不需要某些方法，则系统的耦合性会变高

继承是静态的，不能再程序运行时发生改变

总的来说：
尽量使用对象组合，而不是继承来达到复用的目的。复用时要尽量使用组合/聚合关系（关联关系），少用继承。需要慎重使用继承复用。

创建型设计模式

1.单例模式

有两种模式

1.懒汉模式：在类的声明阶段直接声明一个静态成员变量并初始化赋空间

2.饿汉模式：做声明判断，当静态成员为null的时候初始化，当其不为null的时候直接给出这个静态成员。

懒汉模式直接不推荐，大概率会造成资源的浪费。饿汉模式的话，在多线程情况下可能会出问题，是线程不安全的。调用方法之前要判断有没有类的实例，如果没有，则创建并返回，如果有了就要返回之前的，而不是直接通过这个静态对象是否为null来判断，这个时候就需要枷锁来解决多线程下，单例不安全的问题。

实现起来也很简单，就创建一个lock来实现就可以了(c#),lock是c#的一个语法糖，相当于一个自带的mutex互斥锁，就不用自己写了。也就是说lock()锁定的代码段当有一个线程正在执行的时候会强行占用这一段，其他进程再来调用这段代码的时候就会进行阻塞，前一个线程结束这段执行的时候，这段代码才会放开，交由排队等待的线程执行这段代码。

new指令会执行三个命令 ：

1.在内存中开辟空间
2.执行构造函数，创建对象
3.把空间只想我们创建的对象

一般是 执行 123，但是有时候可能会执行 132，这个时候这个new指令就有可能会出问题，当并发量大的时候，就有可能会出问题，会在执行1 3 2 的时候，有可能会返回一个错误的（空）对象

这个就不多说了，我在Active Server上用的全是这个单例模式，笑了（

简单工厂模式

这个比较蠢，没多大用，就是一个类给一个Init函数去初始化这个类，然后就可以在这个类内进行一些初始化运作，让这个类变成需要的指定的对象类。

不推荐这么用，因为有更好的方法可以完全继承这个方案的优点而摒弃它的缺点

不给代码示例了，其实这个有点像我第一次做的那个师生对讲，我当时想着让一个软件包含教师端和学生端的代码，然后通过命令行参数去确定打开的具体是什么软件，这显然是不可行的，如果这样做的话，那就是简单工厂模式

这个模式有几个很严重的问题：

1.不好维护，维护这个工厂的话必然会违反开闭原则，比如我想要修改一个启动项，那必然就修改了这个工厂的开闭原则了。也就是只增不改原则

2.这样学生端和教师端的代码就缠在一起，维护是一件非常麻烦的事，不仅对我，对任何一个人都非常不友好。

工厂模式

工厂模式的话 与那种简单工厂模式差不多，但是工厂里面是直接生出了一个类对象，就是工厂里面生产出产品，而不是工厂把自己变成产品

//日志记录器工厂
class LoggerFactory {
	//静态工厂方法，工厂LoggerFactory生成了产品Logger
	public static Logger createLogger(String args) {
		if(args.equalsIgnoreCase("db")) {
			//连接数据库，代码省略
			//创建数据库日志记录器对象
			Logger logger = new DatabaseLogger(); 
			//初始化数据库日志记录器，代码省略
			return logger;
		}
		else if(args.equalsIgnoreCase("file")) {
			//创建日志文件
			//创建文件日志记录器对象
			Logger logger = new FileLogger(); 
			//初始化文件日志记录器，代码省略
			return logger;			
		}
		else {
			return null;
		}
	}
}

这个 感觉比较好理解，就是让一个工厂去初始化一个类，但是一个类既然有自己的构造函数，那为什么还需要一个工厂去做呢...

问题还是很明显的，就是还是需要大量的if else，维护这个接口必然会破坏开闭原则，所以不怎么用，知道有这么回事就行了

抽象工厂模式

提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。

举个例子：

abstract class AbstractFactory {
public abstract AbstractProductA createProductA(); //工厂方法一
public abstract AbstractProductB createProductB(); //工厂方法二
……


class ConcreteFactory1 extends AbstractFactory {
	//工厂方法一
public AbstractProductA createProductA() {
	return new ConcreteProductA1();
}

//工厂方法二
public AbstractProductB createProductB() {
	return new ConcreteProductB1();
}

……

与工厂方法模式一样，抽象工厂模式也可为每一种产品提供一组重载的工厂方法，以不同的方式对产品对象进行创建。

抽象工厂增加新的产品族（纵向）是符合开闭原则的，只需要新增新的工厂即可，而需要新增新的产品等级结构（横向）时则不符合开闭原则，这会需要在抽象工厂中新增一个抽象方法C，而修改了抽象工厂就会导致它的所有实现类都需要新增一个方法，这样是不符合开闭原则的。

增加产品族相当于增加一个新的子类（ConcreteFactory）去继承AbstractFactory，没有修改源代码。
增加产品等级结构相当于创建多一种产品，要在工厂类添加多一个方法createProduct（）。
这样理解就行了

原型模式

使用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式是一种对象创建型模式。

这个我感觉就是深拷贝浅拷贝...这个不过多赘述了，我觉得c++程序员应该不会不懂...

建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。

总的来说，我感觉建造者模式就是给一个对象分块，比如一个人，他有四肢和脑袋，然后四肢和脑袋 各有不同又有很多细节，所以在造一个人的时候可以一部分一部分的构建，然后放到一起，我们管这个拼接起来的东西叫做人

class Product  {
 private  String partA; //定义部件，部件可以是任意类型，包括值类型和引用类型

 private  String partB;

   private  String partC;

   //partA的Getter方法和Setter方法省略

   //partB的Getter方法和Setter方法省略

   //partC的Getter方法和Setter方法省略

}

abstract class Builder {
 //创建产品对象

   protected  Product product=new Product();

  

   public  abstract void buildPartA();

   public  abstract void buildPartB();

   public  abstract void buildPartC();

  

 //返回产品对象

   public  Product getResult() {
          return  product;

   }

}

七个结构型模式

适配器模式

将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

这个就比较像CLR，链接.net和c++的，中间件就叫Wrapper，这个我巨懂，不多说了

桥接模式

将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

在具体编码实现时，由于在桥接模式中存在两个独立变化的维度，为了使两者之间耦合度降低，首先需要针对两个不同的维度提取抽象类和实现类接口，并建立一个抽象关联关系。对于“实现部分”维度，典型的实现类接口代码如下所示：

interface Implementor {
	public void operationImpl();
}

在实现Implementor接口的子类中实现了在该接口中声明的方法，用于定义与该维度相对应的一些具体方法。对于另一“抽象部分”维度而言，其典型的抽象类代码如下所示：

abstract class Abstraction {
	protected Implementor impl; //定义实现类接口对象

public void setImpl(Implementor impl) {
	this.impl=impl;
}

public abstract void operation();  //声明抽象业务方法
}

在抽象类Abstraction中定义了一个实现类接口类型的成员对象impl，再通过注入的方式给该对象赋值，一般将该对象的可见性定义为protected，以便在其子类中访问Implementor的方法，其子类一般称为扩充抽象类或细化抽象类(RefinedAbstraction)，典型的RefinedAbstraction类代码如下所示：

class RefinedAbstraction extends Abstraction {
	public void operation() {
		//业务代码
		impl.operationImpl();  //调用实现类的方法
		//业务代码
	}
}

对于客户端而言，可以针对两个维度的抽象层编程，在程序运行时再动态确定两个维度的子类，动态组合对象，将两个独立变化的维度完全解耦，以便能够灵活地扩充任一维度而对另一维度不造成任何影响。