设计模式---设计原则

• 介绍

什么是设计模式：就是一种大家都经常使用的一种解决方案，是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。设计模式不区分语言，只要是面向对象程序中都可以使用。

通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

 

为什么要使用设计模式：可以提高代码可读性、可扩展性，让代码更容易被他人理解、保证代码可靠性。

 

设计原则：

Single Responsibility Principle : 单一职责原则

Liskov Substitution Principle     : 里氏替换原则

Dependence Inversion Principle ：依赖倒置原则

Interface Segregation Principle  : 接口隔离原则

Law of Demeter          : 迪米特法则

Open Closed Principle             : 开闭原则

面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。设计模式根据这结设计原则进行设计总结。

软件开发之所以会有这些原则，就是因为复杂多变且不可预料的需求。并不是说在实际项目开发中对这六大原则中的每一条都遵循到极致，而是说在项目开发的过程中，根据项目的实际需求尽量的去遵守这些原则。当然要做到这些肯定是不容易的，能真正做到并且做好的恐怕也只能是有经验之人。

1、开闭原则（Open Close Principle）

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2、里氏代换原则（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3、依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）

合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

单一职责原则：

应该有且只有一个原因引起类的变更。换句话说就是一个接口只做一件事，即一个职责一个接口。但是困难的是划分职责时并没有一个标准，最终都是需要从实际的项目去考虑。我们在设计的时候，尽量单一，然后对于其实现类就要多方面的考虑。不能死套单一职责原则，否则会增加很多类，给维护带来不便。

一个类只负责一个功能领域中的相应职责，就一个类而言，类的设计尽量做到只有一个原因可以引起它的改变。

 

一个User类图，目前有属性与使用方法：明显不符合单一原则。

 

 

 

通过改造成后，把具体业务放到service层，创建user 操作对象

 

总结：接口一定做到单一职责，类的设计尽量做到只有一个原因可以引起它的改变。

 

里氏替换原则：

 

里氏替换原则简单易懂一点的定义就是只要父类出现的地方子类就可以出现，且替换成子类也不会出现任何错误或者异常。(但是反过来，有子类出现的地方，父类不一定可以适用)。

在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。例如：我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。

 

abstract class AbstractGun{

    

    public abstract void shoot();    

    

}

class Handgun extends AbstractGun {

 

    @Override

    public void shoot() {

        System.out.println("Handgun shoot ......");        

    }

    

}

class Machinegun extends AbstractGun {

 

    @Override

    public void shoot() {

        System.out.println("Machinegun shoot ......");        

    }

    

}

class Solider{

    private AbstractGun gun;
//此处的AbstractGun gun 是父类出现的地方，子类可以出现 体现在传给它的实际参数类型可以是Machinegun或者Handgun任一种类型，并且都不会出错

    public void setGun(AbstractGun gun){

        this.gun = gun;

    }

    public void kill(){

        this.gun.shoot();

    }

}public class Client{

    public static void main(String[] args){

        Solider solider = new Solider();

        //传入的时候并不知道是哪种类型 ，运行时才知道，而且修改枪支的类型只需要new 不同的对象即可。而不用修改其他的任何地方

        solider.setGun(new Machinegun());

        solider.kill();

        

    }

}

 

 

 

 

依赖倒置原则：

所谓依赖倒置原则，就是不论高层组件和低层组件都应该依赖于抽象，而不是具体实现类。听起来更像是“针对接口编程，而不是针对实现编程”，但是这里依赖倒置原则更强调“抽象”的概念，不要让高层组件依赖低层组件，更不能依赖具体实现类，都要依赖于抽象。依赖倒置原则的核心在于“面向接口编程”，目的在于”解耦“。

模块间的依赖关系通过接口和抽象类产生，实体类之间不直接发生依赖关系

在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。

interface Car{

    public void run();

}

class Benz implements Car{

    

    public void run(){

        System.out.println("benz run......");

    }

    

}class BMW implements Car{

    

    public void run(){

        System.out.println("bmw run......");

    }

    

}

class Driver{

       //让Driver类依赖一个Car这个接口

    public void drive(Car car){

        car.run();

    }

    

}
public class Client{

    public static void main(String[] args){

        Driver driver = new Driver();

        driver.drive(new BMW());

    }

}

  

 

 

 

 

接口隔离原则：

1. 定义: 建立单一接口，不要建立臃肿庞大的接口。即接口尽量细化，同时接口中的方法尽量少。在这里提一下单一职责和接口隔离原则的区别。首先两个侧重点是不一样的.单一职责要求类和接口，或者方法的职责单一，侧重点在职责，这是根据业务逻辑进行划分的。而接口隔离原则要接口中的方法尽量少。比如，一个接口或者一个中有十个方法，不同的方法做不同的事情.
2. 使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

　接口隔离原则是对接口定义的规范。含义主要包含以下4点。

①接口尽量小。根据具体业务把一个接口按照接口隔离原则细化成更多的接口。但是在此基础之上必须不能违背单一职责原则。

②接口要高内聚。高内聚的意思就是提高接口和类处理能力，减少对外的交互。接口是对外的承诺，因此设计时应该尽量少公布接口中的public方法，承诺越少系统开发越有利且变更风险就越少。

③定制服务。定制服务就是单独为一个个体提供服务，即只提供访问者需要的方法。举一个图书管理系统的例子，有一个查询接口BookSearch，包括如下方法:searchById,searchByBookName,searchByCategory,complexSearch,其中前三个方法是提供给学生使用的，后一个方法是提供给管理员使用的，学生对这个方法的访问是有限制的，调用不会返回任何值。当这四个方法全部公布出去之后，学生对此方法的访问即使不返回任何值也会使服务器性能下降。因此合理的设计应该是拆分这个接口为两个接口:SimpleSearch和AdminSearch。SimpleSearch接口提供searchById,searchByBookName,searchByCategory方法，AdminSearch接口提供complexSearch方法，此时学生实现SimpleSearch接口即可，管理员同时实现SimpleSearch和AdminSearch两个接口。

④接口设计是有限度的。接口设计越小越好，但是结构同时会变得复杂，维护也变得难了。因此就要把握住这个度。

 

迪米特法则：

一个软件实体应当尽可能少地与其他实体发生相互作用

1. 定义: 迪米特法则也叫做最少知识原则(Least Knowledge Principle,LKP)，即一个对象应该对其他对象有最少的了解，也就是说一个类要对自己需要耦合或者调用的类知道的最少。我只知道你有多少public方法可以供我调用，而其他的一切都与我无关。

2. 迪米特法则是对类的低耦合做处理明确的要求，在此举一个例子：学校领导老师点名，老师让体育委员清点人数。其中第二段代码的耦合性较第一段代码有所改善。

 

 

 

 

 

迪米特法则的核心观念就是类间解耦，最终可能产生的结果就是会产生了大量的中转类。为了把解耦做到极致导致实现一个业务逻辑的实现跳转了很多类，这也是不可取的做法。因此根据实际权衡利弊才是重要的。

 

开闭原则：

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

1. 定义：开闭原则是Java里最基础的设计原则。具体的定义是：一个软件实体，比如类，模块，函数应该对扩展开放，对修改关闭。说的通熟易懂一些就是一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现改变。
2. 不要修改源代码，设计出可以扩展方式。

 

 

 

 

设计模式分类：

设计模式分为三种类型，共23种：

创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。

结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。

行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。