设计模式

设计模式简介

定义

设计模式是一套面向对象的代码设计经验总结，是在编程领域被反复使用、被多数人知晓、而且经过分类整理的代码设计方法。

奠基人

四人帮

实质

是一种思想(占绝大多数)，也是一种技术
是一种解决方案，开发者可快速完成某项工作
指明开发方向，快速达成目标

目的*

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)，具有更好的以下方面的优点：

代码重用性 (即：相同功能的代码，不用多次编写)
可读性 (即：编程规范性, 便于其他程序员的阅读和理解)
可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护)
使程序呈现高内聚，低耦合的特性
让代码编写实现工程化

金句

设计模式包含了面向对象的精髓，“懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要”
Scott Mayers 在其巨著《Effective C++》就曾经说过：C++老手和 C++新手的区别就是前者手背上有很多伤疤

设计模式七大原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么这样设计的依据)

单一职责原则
接口隔离原则
依赖倒转(倒置)原则
里氏替换原则
开闭原则
迪米特法则
合成复用原则

单一职责原则

定义

对于一个类，应该只有一个引起它变化的原因

违背单一原则实例

一个负责接收用户发来信息的类，可能会被设计为还可以访问数据库，并将用户发来的信息进行记录。
数据持久层变化、用户发送信息结构改变，都会引起这个类也要做出相应的改变（引起这个类发生变化的原因有两个，违背单一职责原则）

缺点

一个类职业庞大，维护更加麻烦，可复用性随之降低

单一职责优点

易于维护（避免修改一个功能从而影响到其他功能出现问题）
高度可复用性
降低类的复杂度，一个类只负责一项原则，逻辑简单
提高类的可读性，可维护性
降低变更引起的风险

实例

查看不同交通工具的运行情况

方案一

/**
 * 交通工具类
 */
class Vehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + " 在公路上运行....");
	}
}

/**
 * 客户端
 */
public class SingleResponsibility1 {
	
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Vehicle vehicle = new Vehicle();
		vehicle.run("摩托车");
		vehicle.run("汽车");
		vehicle.run("飞机");
	}

}

分析

在方式1 的run方法中，违反了单一职责原则。如果变更需求，比如多加飞机的交通工具，再比如多加轮船的交通工具，使原有的设计出现问题。Vehicle类职责过多，变更更容易带来风险。

改进

根据交通工具运行方法不同，分解成不同类即可

方案二

/**
 * 陆地交通工具
 */
class RoadVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + "公路运行");
	}
}

/**
 * 空中交通工具
 */
class AirVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + "天空运行");
	}
}

/**
 * 水中交通工具
 */
class WaterVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle + "水中运行");
	}
}

/**
 * 客户端
 */
public class SingleResponsibility2 {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		RoadVehicle roadVehicle = new RoadVehicle();
		roadVehicle.run("摩托车");
		roadVehicle.run("汽车");
		
		AirVehicle airVehicle = new AirVehicle();
		
		airVehicle.run("飞机");
	}

}

分析

虽然遵守单一职责原则，但是这样做的改动很大，即将类分解，同时修改客户端。这里只是三个职责，还不明显，如果职责有很多，那么弊端就非常明显了。

改进

直接修改Vehicle 类，改动的代码会比较少

方案三

/**
 * 交通工具类，将具体职责拆分成方法
 */
class Vehicle2 {
	
	public void run(String vehicle) {
		System.out.println(vehicle + " 在公路上运行....");
	}
	
	public void runAir(String vehicle) {
		System.out.println(vehicle + " 在天空上运行....");
	}
	
	public void runWater(String vehicle) {
		System.out.println(vehicle + " 在水中行....");
	}

}

/**
 * 客户端
 */
public class SingleResponsibility3 {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Vehicle2 vehicle2  = new Vehicle2();
		vehicle2.run("汽车");
		vehicle2.runWater("轮船");
		vehicle2.runAir("飞机");
	}

}

分析

这种修改方法没有对原来的类做大的修改，只是增加方法
这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责。当时却减少了修改的操作，更符合实际开发的情况。

单一职责原则扩展（什么时候可以违反）

原因

职责扩散（特定原因职责A被分化为A1,A2）

单一职责原则违反情况

需要足够简单的逻辑，才可在代码级别违反单一职责原则
需要类中方法数量足够少，才可以在方法级别上违反单一职责原则

接口隔离原则

定义

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

实例

方案一

在这里插入图片描述

//接口
interface Interface1 {
	void operation1();
	void operation2();
	void operation3();
	void operation4();
	void operation5();
}

class B implements Interface1 {
	@Override
	public void operation1() {
		System.out.println("B 实现了 operation1");
	}
	@Override
	public void operation2() {
		System.out.println("B 实现了 operation2");
	}
	@Override
	public void operation3() {
		System.out.println("B 实现了 operation3");
	}
	@Override
	public void operation4() {
		System.out.println("B 实现了 operation4");
	}
	@Override
	public void operation5() {
		System.out.println("B 实现了 operation5");
	}
}

class D implements Interface1 {
	@Override
	public void operation1() {
		System.out.println("D 实现了 operation1");
	}
	@Override
	public void operation2() {
		System.out.println("D 实现了 operation2");
	}
	@Override
	public void operation3() {
		System.out.println("D 实现了 operation3");
	}
	@Override
	public void operation4() {
		System.out.println("D 实现了 operation4");
	}
	@Override
	public void operation5() {
		System.out.println("D 实现了 operation5");
	}
}

/**
 * A 类通过接口Interface1 依赖(使用) B类，但是只会用到1,2,3方法
 */
class A { 
	public void depend1(Interface1 i) {
		i.operation1();
	}
	public void depend2(Interface1 i) {
		i.operation2();
	}
	public void depend3(Interface1 i) {
		i.operation3();
	}
}

/**
 * C 类通过接口Interface1 依赖(使用) D类，但是只会用到1,4,5方法
 */
class C { 
	public void depend1(Interface1 i) {
		i.operation1();
	}
	public void depend4(Interface1 i) {
		i.operation4();
	}
	public void depend5(Interface1 i) {
		i.operation5();
	}
}

分析

没有使用接口隔离原则。类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。

方案二

改进

按隔离原则应当这样处理：
将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
在这里插入图片描述

// 接口1
interface Interface1 {
	void operation1();

}

// 接口2
interface Interface2 {
	void operation2();

	void operation3();
}

// 接口3
interface Interface3 {
	void operation4();

	void operation5();
}

class B implements Interface1, Interface2 {
	@Override
	public void operation1() {
		System.out.println("B 实现了 operation1");
	}

	@Override
	public void operation2() {
		System.out.println("B 实现了 operation2");
	}

	@Override
	public void operation3() {
		System.out.println("B 实现了 operation3");
	}

}

class D implements Interface1, Interface3 {
	@Override
	public void operation1() {
		System.out.println("D 实现了 operation1");
	}

	@Override
	public void operation4() {
		System.out.println("D 实现了 operation4");
	}

	@Override
	public void operation5() {
		System.out.println("D 实现了 operation5");
	}
}

/**
 * A 类通过接口Interface1,Interface2 依赖(使用) B类，但是只会用到1,2,3方法
 */
class A { 
	public void depend1(Interface1 i) {
		i.operation1();
	}

	public void depend2(Interface2 i) {
		i.operation2();
	}

	public void depend3(Interface2 i) {
		i.operation3();
	}
}

/**
 * C 类通过接口Interface1,Interface3 依赖(使用) D类，但是只会用到1,4,5方法
 */
class C { 
	public void depend1(Interface1 i) {
		i.operation1();
	}

	public void depend4(Interface3 i) {
		i.operation4();
	}

	public void depend5(Interface3 i) {
		i.operation5();
	}
}

/**
 * 客户端
 */
public class Segregation1 {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		// 使用一把
		A a = new A();
		a.depend1(new B()); // A类通过接口去依赖B类
		a.depend2(new B());
		a.depend3(new B());

		C c = new C();

		c.depend1(new D()); // C类通过接口去依赖(使用)D类
		c.depend4(new D());
		c.depend5(new D());

	}

}

使用接口隔离原则，一个类对另一个类的依赖应该建立在最小的接口上，避免实现不需要的方法。

依赖倒转原则

定义

高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒转(倒置)的中心思想是面向接口编程

设计理念：

相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类
使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

实质

通过抽象(接口]或抽象类)是各个类或模块的实现彼此独立,不互相影响，从而实现模块间的松耦合依赖倒转原则

规范

每个类尽量都继承自接口或抽象类，或者抽象类和接口两者都具备。
这是依赖倒转的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒转
变量的显示类型尽量是接口或者是抽象类
很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类一般是不需要接口或是抽象类的。另外，如果要使用类的clone方法，就必须使用实现类，这个是JDK提供一个规范
类要尽量避免从具体类派生。
如果一个项目处于开发状态，确实不应该有从具体。类派生出子类情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以接受的。特别是做项目维护的工程师，基本上可以不考虑这个规则，因为维护工作基本上都是做扩展开发、修复行为，通过一个继承关系，覆盖一个方法就可以修正一个很大的Bug，何必再要去继承最高的基类呢?
尽量不要覆盖基类的方法。
如果基类是一个抽象类，而且这个方法已经实现了，子类就尽量不要覆盖。类间依赖的是抽象，覆盖了抽象方法，对依赖的稳定性会产生一定的影响

意义

传统的过程性系统设计办法更加倾向于使高层次模块依赖于低层次模块，抽象的层次依赖于具体的层次。倒转的意义就是把这个错误的依赖关系倒转过来，要求客户端应该依赖于抽象耦合

抽象层

抽象层所包含的应该是应用系统的商务逻辑和宏观的对整个系统来说具有重要的战略性的决定也是必然性的体现。

具体层

具体的层次含有的是一些次要的，与实现有关的算法以及逻辑还有战术性的决定。这些都带有相当大的偶然选择性

扩展——违反依赖倒转原则的情况

如果有一个类的功能很有可能在未来不发生变化，那么不需要使用依赖倒转原则

实例

编程完成 Person 接收消息的功能

方案一

class Email {
	public String getInfo() {
		return "电子邮件信息: hello,world";
	}
}

//完成Person接收消息的功能
class Person {
	public void receive(Email email ) {
		System.out.println(email.getInfo());
	}
}

public class DependecyInversion {

	public static void main(String[] args) {
		Person person = new Person();
		person.receive(new Email());
	}

}

分析

简单，比较容易想到
如果我们获取的对象是微信，短信等等，则新增类，同时Perons也要增加相应的接收方法

改进

解决思路：引入一个抽象的接口IReceiver, 表示接收者, 这样Person类与接口IReceiver发生依赖
因为Email, WeiXin 等等属于接收的范围，他们各自实现IReceiver 接口就ok, 这样我们就符号依赖倒转原则

方案二

//定义接口
interface IReceiver {
	public String getInfo();
}

class Email implements IReceiver {
	@Override
	public String getInfo() {
		return "电子邮件信息: hello,world";
	}
}

//增加微信
class WeiXin implements IReceiver {
	@Override
	public String getInfo() {
		return "微信信息: hello,ok";
	}
}

//方式2
class Person {
	//这里我们是对接口的依赖
	public void receive(IReceiver receiver ) {
		System.out.println(receiver.getInfo());
	}
}

public class DependecyInversion {

	public static void main(String[] args) {
		//客户端无需改变
		Person person = new Person();
		person.receive(new Email());
		
		person.receive(new WeiXin());
	}

}

依赖关系传递的三种方式和应用案例

接口传递

实例

 //ITV接口
interface ITV {
    public void play ();
}

// 开关的接口
interface IOpenAndClose {
    public void open ( ITV tv ); //抽象方法,接收接口
}

class ChangHong implements ITV {
    @Override
    public void play () {
        // TODO Auto-generated method stub
        System.out.println("长虹电视机，打开");
    }
}

// 实现接口
class OpenAndClose implements IOpenAndClose {
    public void open ( ITV tv ) {
        tv.play();
    }
}

public class DependencyPass {
    public static void main ( String[] args ) {
        ChangHong changHong = new ChangHong();
		OpenAndClose openAndClose = new OpenAndClose();
		//通过接口方式传递依赖
		openAndClose.open(changHong);   
    }
}

构造方法传递

实例

interface IOpenAndClose {
	//抽象方法
	public void open (); 
}

//ITV接口
interface ITV { 
	public void play ();
}

class OpenAndClose implements IOpenAndClose {
	public ITV tv; //成员

	public OpenAndClose ( ITV tv ) { //构造器
		this.tv = tv;
	}

	public void open () {
		this.tv.play();
	}
}

public class DependencyPass {

    public static void main ( String[] args ) {
        ChangHong changHong = new ChangHong();
		        //通过构造器进行依赖传递
		OpenAndClose openAndClose = new    OpenAndClose(changHong);
		openAndClose.open();
 
    }

}

setter 方式传递

实例

interface IOpenAndClose {
    public void open (); // 抽象方法

    public void setTv ( ITV tv );
}

interface ITV { 
    public void play ();
}

class OpenAndClose implements IOpenAndClose {
    private ITV tv;

    @Override
    public void setTv ( ITV tv ) {
        this.tv = tv;
    }

    @Override
    public void open () {
        this.tv.play();
    }
}

class ChangHong implements ITV {
    @Override
    public void play () {
        System.out.println("长虹电视机，打开");
    }
}

 public static void main ( String[] args ) {
        ChangHong changHong = new ChangHong();
        //通过setter方法进行依赖传递
        OpenAndClose openAndClose = new OpenAndClose();
        openAndClose.setTv(changHong);
        openAndClose.open();
 }

依赖倒转原则的注意事项和细节

低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
继承时遵循里氏替换原则

里氏替换原则

定义

子类型必须能够替换掉他们的父类型，并且不影响程序的功能（行为），是对实现抽象化的具体步骤的规范。

简介

如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。
在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。

继承

把父类多元化，产生多种子类，又保留父类的公共特征
子类有自身特征，也继承了父类的公共特征
继承者（子类）可以理解为被继承者（父类）的特殊化

面向对象中的定义

继承是使用已存在的类的定义作为基础去建立新类的技术，已存在的类是父类，创建的新类是已存在的类的子类，子类可以增加新的方法，也可以用父类的方法，但不能选择性的继承父类。
继承所表达的是一种相交的关系，一个类对象可以继承另一个类的数据成员和成员方法

实例

继承引发的问题

class A {
	// 返回两个数的差
	public int func1(int num1, int num2) {
		return num1 - num2;
	}
}

/**
 * B类继承了A
 * 增加了一个新功能：完成两个数相加,然后和9求和
 */
class B extends A {
	//这里，重写了A类的方法, 可能是无意识
	public int func1(int a, int b) {
		return a + b;
	}

	public int func2(int a, int b) {
		return func1(a, b) + 9;
	}
}

public class Liskov {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		A a = new A();
		System.out.println("11-3=" + a.func1(11, 3));
		System.out.println("1-8=" + a.func1(1, 8));

		System.out.println("-----------------------");
		B b = new B();
		System.out.println("11-3=" + b.func1(11, 3));//这里本意是求出11-3，可求出的却是11+3
		System.out.println("1-8=" + b.func1(1, 8));// 这里本意是求出1-8，可求出的却是1+8
		System.out.println("11+3+9=" + b.func2(11, 3));
	}

}

分析

原来运行正常的相减功能发生了错误。原因就是类 B 无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候

改进

通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替.

/**
 * 创建一个更加基础的基类
 */
class Base {
	//把更加基础的方法和成员写到Base类
}

class A extends Base {
	// 返回两个数的差
	public int func1(int num1, int num2) {
		return num1 - num2;
	}
}

/**
 * B类继承了A
 * 增加了一个新功能：完成两个数相加,然后和9求和
 */
class B extends Base {
	//如果B需要使用A类的方法,使用组合关系
	private A a = new A();
	
	//这里，重写了A类的方法, 可能是无意识
	public int func1(int a, int b) {
		return a + b;
	}

	public int func2(int a, int b) {
		return func1(a, b) + 9;
	}
	
	//我们仍然想使用A的方法
	public int func3(int a, int b) {
		return this.a.func1(a, b);
	}
}

public class Liskov {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		A a = new A();
		System.out.println("11-3=" + a.func1(11, 3));
		System.out.println("1-8=" + a.func1(1, 8));

		System.out.println("-----------------------");
		B b = new B();
		//因为B类不再继承A类，因此调用者，不会再func1是求减法
		//调用完成的功能就会很明确
		System.out.println("11+3=" + b.func1(11, 3));//这里本意是求出11+3
		System.out.println("1+8=" + b.func1(1, 8));// 1+8
		System.out.println("11+3+9=" + b.func2(11, 3));
		
		//使用组合仍然可以使用到A类相关方法
		System.out.println("11-3=" + b.func3(11, 3));// 这里本意是求出11-3
	}

}

开闭原则

是面向对象开发中所有原则的核心，关键是实现抽象化，并且从抽象化得到具体的实例

定义

程序的实体对象(模块、类、函数等)应该可以进行扩展,但不应该可以修改

理解

对已有程序的扩展优先采用添加新的类或者模块的方式来进行,而不是通过修改现有的类或模块来进行
一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

原因

软件设计的本身所追求的目标是封装变化、降低耦合，开放封闭原则就是对这个目标的直接实现（里氏代换原则也是为了实现这个目标——通过实现最佳的、正确的继承层次）

特征

对扩展是开放
对修改是封闭的——开放-封闭原则(核心)

意义

核心思想是面向抽象编程，而不是面向具体编程，因为抽象相对来说是稳定的。
让类依赖于固定的抽象，所以对于修改来说是封闭的；通过面向对象的继承及多态机制，可以实现对抽象体的继承，通过重写其方法，来改变固有行为，从而实现新的扩展方法，所以对于扩展来说是开放的
开放封闭原则可以通过扩展已有软件系统提供新的行为,以满足软件的新需求,使变化中的软件有一定的适应性和灵活性
对于已有的软件模块，特别是最重要的抽象模块不能再修改,这就使变化中的软件系统有一定的稳定性和延续性

实例

实现一个画图功能

方案一

在这里插入图片描述

//Shape类，基类
class Shape {
	int m_type;
}

//矩形
class Rectangle extends Shape {
	Rectangle() {
		super.m_type = 1;
	}
}

//圆形
class Circle extends Shape {
	Circle() {
		super.m_type = 2;
	}
}

//新增画三角形
class Triangle extends Shape {
	Triangle() {
		super.m_type = 3;
	}
}

/**
 * 这是一个用于绘图的类 [使用方]
 */
class GraphicEditor {
	//接收Shape对象，然后根据type，来绘制不同的图形
	public void drawShape(Shape s) {
		if (s.m_type == 1) {
			drawRectangle(s);
		} else if (s.m_type == 2) {
			drawCircle(s);
		} else if (s.m_type == 3) {
			drawTriangle(s);
		}
	}

	//绘制矩形
	public void drawRectangle(Shape r) {
		System.out.println(" 绘制矩形 ");
	}

	//绘制圆形
	public void drawCircle(Shape r) {
		System.out.println(" 绘制圆形 ");
	}
	
	//绘制三角形
	public void drawTriangle(Shape r) {
		System.out.println(" 绘制三角形 ");
	}
}

public class Ocp {
	public static void main(String[] args) {
		//使用看看存在的问题
		GraphicEditor graphicEditor = new GraphicEditor();
		graphicEditor.drawShape(new Rectangle());
		graphicEditor.drawShape(new Circle());
		graphicEditor.drawShape(new Triangle());
	}
}

分析

优点是比较好理解，简单易操作。
缺点是违反了设计模式的 ocp 原则，即对扩展开放(提供方)，对修改关闭(使用方)。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
比如我们这时要新增加一个图形种类三角形，修改的地方较多

改进

思路：把创建 Shape 类做成抽象类，并提供一个抽象的 draw 方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承 Shape，并实现 draw 方法即可，使用方的代码就不需要修 -> 满足了开闭原则

//这是一个用于绘图的类 [使用方]
class GraphicEditor {
	//接收Shape对象，调用draw方法
	public void drawShape(Shape s) {
		s.draw();
	}
}

//Shape类，基类
abstract class Shape {
	int m_type;
	public abstract void draw();//抽象方法
}

class Rectangle extends Shape {
	Rectangle() {
		super.m_type = 1;
	}

	@Override
	public void draw() {
		System.out.println(" 绘制矩形 ");
	}
}

class Circle extends Shape {
	Circle() {
		super.m_type = 2;
	}
	@Override
	public void draw() {
		System.out.println(" 绘制圆形 ");
	}
}

//新增画三角形
class Triangle extends Shape {
	Triangle() {
		super.m_type = 3;
	}
	@Override
	public void draw() {
		System.out.println(" 绘制三角形 ");
	}
}

//新增一个图形
class OtherGraphic extends Shape {
	OtherGraphic() {
		super.m_type = 4;
	}
	@Override
	public void draw() {
		System.out.println(" 绘制其它图形 ");
	}
}

public class Ocp {

	public static void main(String[] args) {
		GraphicEditor graphicEditor = new GraphicEditor();
		graphicEditor.drawShape(new Rectangle());
		graphicEditor.drawShape(new Circle());
		graphicEditor.drawShape(new Triangle());
		graphicEditor.drawShape(new OtherGraphic());
	}

}

迪米特法则(最少知道原则)

定义

如果两个类之间不必直接通信，则这两个类不应该发生直接的相互作用,如果其中一个类需要调用另一个类的某个方法,可以通过第三方来转发这个调用

根本思想

类之间需要尽量多实现松散耦合,耦合越弱,越有利于复用。信息的隐藏会促进软件的复用

前提

每一个类都要尽量降低成员的访问权限，类自己包装好自己的private状态，不需要让别的类知道的字段或者行为就不要公开
尽可能降低属性或方法的权限

基本介绍

一个对象应该对其他对象保持最少的了解
类与类关系越密切，耦合度越大
. 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息
迪米特法则还有个更简单的定义：只与直接的朋友通信
直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，**我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。**也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

实例

有一个学校，下属有各个学院和总部，现要求打印出学校总部员工 ID 和学院员工的 id

方案一

/学校总部员工类
class Employee {
	private String id;

	public void setId(String id) {
		this.id = id;
	}

	public String getId() {
		return id;
	}
}


//学院的员工类
class CollegeEmployee {
	private String id;

	public void setId(String id) {
		this.id = id;
	}

	public String getId() {
		return id;
	}
}


//管理学院员工的管理类
class CollegeManager {
	//返回学院的所有员工
	public List<CollegeEmployee> getAllEmployee() {
		List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
		for (int i = 0; i < 10; i++) { //这里我们增加了10个员工到 list
			CollegeEmployee emp = new CollegeEmployee();
			emp.setId("学院员工id= " + i);
			list.add(emp);
		}
		return list;
	}
}

//学校管理类

//分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
//CollegeEmployee 不是 直接朋友 而是一个陌生类，这样违背了 迪米特法则 
class SchoolManager {
	//返回学校总部的员工
	public List<Employee> getAllEmployee() {
		List<Employee> list = new ArrayList<Employee>();
		
		for (int i = 0; i < 5; i++) { //这里我们增加了5个员工到 list
			Employee emp = new Employee();
			emp.setId("学校总部员工id= " + i);
			list.add(emp);
		}
		return list;
	}

	//该方法完成输出学校总部和学院员工信息(id)
	void printAllEmployee(CollegeManager sub) {
		
		//分析问题
		//1. 这里的 CollegeEmployee 不是  SchoolManager的直接朋友
		//2. CollegeEmployee 是以局部变量方式出现在 SchoolManager
		//3. 违反了 迪米特法则 
		
		//获取到学院员工
		List<CollegeEmployee> list1 = sub.getAllEmployee();
		System.out.println("------------学院员工------------");
		for (CollegeEmployee e : list1) {
			System.out.println(e.getId());
		}
		//获取到学校总部员工
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("------------学校总部员工------------");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}
}

//客户端
public class Demeter1 {

	public static void main(String[] args) {
		//创建了一个 SchoolManager 对象
		SchoolManager schoolManager = new SchoolManager();
		//输出学院的员工id 和  学校总部的员工信息
		schoolManager.printAllEmployee(new CollegeManager());

	}

}

分析

SchoolManager学校管理类中不应该出现CollegeEmployee类，违背了迪米特法则。将CollegeEmployee类员工信息交由CollegeManager学院管理类来管理。按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。

改进

//学校总部员工类
class Employee {
	private String id;

	public void setId(String id) {
		this.id = id;
	}

	public String getId() {
		return id;
	}
}


//学院的员工类
class CollegeEmployee {
	private String id;

	public void setId(String id) {
		this.id = id;
	}

	public String getId() {
		return id;
	}
}


//管理学院员工的管理类
class CollegeManager {
	//返回学院的所有员工
	public List<CollegeEmployee> getAllEmployee() {
		List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
		for (int i = 0; i < 10; i++) { //这里我们增加了10个员工到 list
			CollegeEmployee emp = new CollegeEmployee();
			emp.setId("学院员工id= " + i);
			list.add(emp);
		}
		return list;
	}
	
	//输出学院员工的信息
	public void printEmployee() {
		//获取到学院员工
		List<CollegeEmployee> list1 = getAllEmployee();
		System.out.println("------------学院员工------------");
		for (CollegeEmployee e : list1) {
			System.out.println(e.getId());
		}
	}
}

//学校管理类

//分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
class SchoolManager {
	//返回学校总部的员工
	public List<Employee> getAllEmployee() {
		List<Employee> list = new ArrayList<Employee>();
		
		for (int i = 0; i < 5; i++) { //这里我们增加了5个员工到 list
			Employee emp = new Employee();
			emp.setId("学校总部员工id= " + i);
			list.add(emp);
		}
		return list;
	}

	//该方法完成输出学校总部和学院员工信息(id)
	void printAllEmployee(CollegeManager sub) {
		
		//分析问题
		//1. 将输出学院的员工方法，封装到CollegeManager
		sub.printEmployee();
	
		//获取到学校总部员工
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("------------学校总部员工------------");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}
}

public static void main(String[] args) {
		System.out.println("~~~使用迪米特法则的改进~~~");
		//创建了一个 SchoolManager 对象
		SchoolManager schoolManager = new SchoolManager();
		//输出学院的员工id 和  学校总部的员工信息
		schoolManager.printAllEmployee(new CollegeManager());

}

迪米特法则注意事项和细节

迪米特法则的核心是降低类之间的耦合
但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系，并不是要求完全没有依赖关系

合成复用原则

定义

尽量不使用类继承，而尽量使用合成/聚合。优先使用对象的合成/聚合会有助于保持系统上的每个类都会被封装，并且类被集中在单个任务上

理解

聚合

本质是引用的聚合
是一种比较“强”的拥有关系，体现的是严格的整体与部分的关系，并且整体与部分有着相同的生命周期

合成

本质是值的聚合
是一种比较“强”的拥有关系，体现的是严格的整体与部分的关系，并且整体与部分有着相同的生命周期

“Is-A”

代表一个类是另外一个类的一种
存在明确的“Is-A”关系，并且关系稳定不变的考虑使用继承
两个类必须符合里氏代换原则才可以是“Is-A”的关系（子类型必须能够替换父类型，并且不影响程序的运行）

“Has-A”

代表一个类是另外一个类的一个角色

例子

鱼和鱼群是聚合关系，手臂和人是合成关系
人为一个类，“管理者”、“大学生”、“员工”为人的子类。如果在继承的角度上考虑，是不合常理的（一个人是大学生，那么就不能是管理者）。所以应当使用合成

优点

类和类之间的继承层次可以保持比较小的规模，并且不太可能增长为不可控制的巨大单位
新的对象存取子对象的唯一方法是通过子对象的接口
这种复用是黑箱的复用，因为子对象的内部细节是新对象所看不见的
更好地支持封装的特性
实现上的相互依赖性是比较小的
每一个新的类都可以将焦点集中在一个任务之上
可以在运行时动态地进行，新的对象可以动态地引用与子对象类型相同的对象
可以应用到任何环境中去

缺点

会有较多的对象需要管理

使用条件

子类是父类的一个特殊种类( “Has-A” )，而不是父类的个角色时( “Is-A” )
永远不会出现需要将子类替换成另外个类的子类的情况
子类具有扩展父类的责任，而不是重写父类的方法时
只有在分类学角度上有意义时，才可以使用继承

实例一

在这里插入图片描述

实例二

大将军与士兵是聚合关系（大将军可以拥有士兵，但士兵不是大将军的一部分，因为大将军不可能拥有所有的士兵）；皇帝与大将军是合成关系（皇帝拥有天下，大将军是皇帝所拥有的一部分）
将大臣与士兵分别设计成接口
将军实现大臣的接口，并拥有士兵接口的集合（聚合）
具体士兵实现士兵接口
皇帝拥有大臣的接口集合

设计原则核心思想

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
针对接口编程，而不是针对实现编程。
为了交互对象之间的松耦合设计而努力

koala丶

发布了23 篇原创文章 · 获赞 15 · 访问量 3727

私信关注

设计模式(一)——七大原则详解

设计模式

设计模式简介

定义

奠基人

实质

目的*

金句

设计模式七大原则

单一职责原则

定义

违背单一原则实例

缺点

单一职责优点

实例

方案一

分析

改进

方案二

分析

改进

方案三

分析

单一职责原则扩展（什么时候可以违反）

原因

单一职责原则违反情况

接口隔离原则

定义

实例

方案一

分析

方案二

改进

依赖倒转原则

定义

设计理念：

实质

规范

意义

抽象层

具体层

扩展——违反依赖倒转原则的情况

实例

方案一

分析

改进

方案二

依赖关系传递的三种方式和应用案例

接口传递

实例

构造方法传递

实例

setter 方式传递

实例

依赖倒转原则的注意事项和细节

里氏替换原则

定义

简介

继承

面向对象中的定义

实例

继承引发的问题

分析

改进

开闭原则

定义

理解

原因

特征

意义

实例

方案一

分析

改进

迪米特法则(最少知道原则)

定义

根本思想

前提

基本介绍

实例