七大软件设计原则

评价java程序员技术的好坏，不一定是会多少新技术。有一点也是很重要。就是代码质量。代码是否易读、美观、易于维护、可扩展性强。所以一个优秀的程序员，不能一味的追求新技术。在我看来，将自己的代码写的优雅。也是实力的体现。

学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原 则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。

1.开闭原则 （Open-Closed Principle）

定义：

开闭原则(Open-Closed Principle, OCP) 是指一个软件实体如类、模块和函数应该对扩展开放， 对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如:我们版本更新，我尽可能不修改源代码，但是可以增加新功能。

例子：

生活中的例子：小学生放暑假，老师布置了10篇作文。对于小学生而言，写完这10篇作文这个要求是关闭的，但是具体哪天写，一天写几篇是开放的，由小学生自己决定。

代码：

package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public interface Moto {

    String getId();

    String getName();

    Double getPrice();
}

package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public class CFMoto implements Moto{
    private String id = "";
    private String name = "";
    private Double price = 0.0d;

    public CFMoto(String id, String name, Double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    @Override
    public String getId() {
        return this.id;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public Double getPrice() {
        return this.price;
    }
}

package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public class CFDiscountMoto extends CFMoto{
    private Double discount = 1d;
    public CFDiscountMoto(String id, String name, Double price,Double discount) {
        super(id, name, price);
        this.discount = discount;
    }

    @Override
    public Double getPrice() {
        return super.getPrice();
    }

    public Double getDiscountPrice() {
        return super.getPrice() * discount;
    }
}

package com.xhc.test.design.openclosed;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.openclosed
 */
public class Test {

    public static void main(String[] args) {
        CFMoto cfMoto = new CFMoto("001","春风nk250",19800d);
        System.out.println(cfMoto.getName()+"售价为："+cfMoto.getPrice());

        CFDiscountMoto cfDiscountMoto = new CFDiscountMoto("001","春风nk250",19800d,0.85);
        System.out.println(cfMoto.getName()+"原售价为："+cfDiscountMoto.getPrice()+" 现售价为："+cfDiscountMoto.getDiscountPrice());
    }
}

类图：

2.依赖倒置原则 （Dependence Inversion Principle）

定义：依赖倒置原则(Dependence Inversion Principle,DIP) 是指设计代码结构时，高层模块（调用层）不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节;细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并能够降低修改程序所造成的风险

我们先看一个例子,博主骑摩托车，喜欢改装摩托。

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public class MyMoto {

    //加装风挡
    public void refitWindshield(){
        System.out.println("摩托车加装了风挡");
    }

    //加装防摔棒
    public void refitDropbar(){
        System.out.println("摩托车加装防摔棒");
    }
    
}

package com.xhc.test.design.dependenceInversion;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public class Test {
    public static void main(String[] args) {
        MyMoto myMoto = new MyMoto();
        myMoto.refitDropbar();
        myMoto.refitWindshield();
    }
}

上面的代码有一个问题，就是：如果我还想继续改装排气，那么需要修改两个java类。需要先在MyMoto类中添加一个改装排气的方法，再在test方法中调用；在实际开发过程中，尽可能的不修改老代码（开闭原则）。

改造代码:创建一个改装的接口 Refit.java

package com.xhc.test.design.dependenceInversion;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public interface Refit {
	//改装
    void refit();
}

DropbarRefit.java 防摔棒改装类

package com.xhc.test.design.dependenceInversion;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public class DropbarRefit implements Refit{
    @Override
    public void refit() {
        System.out.println("改装防摔棒");
    }
}

WindshieldRefit.class 风挡改装类

package com.xhc.test.design.dependenceInversion;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public class WindshieldRefit implements Refit{

    @Override
    public void refit() {
        System.out.println("改装风挡");
    }
}

MyMoto.java 我的摩托类

package com.xhc.test.design.dependenceInversion;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public class MyMoto {

    public void upgradeMoto(Refit refit){
        refit.refit();
    }

}

Test.java 测试类

package com.xhc.test.design.dependenceInversion;

/**
 * @author xuehuichen
 * @version V1.0
 * @Package com.xhc.test.design.dependenceInversion
 */
public class Test {
    public static void main(String[] args) {
        MyMoto myMoto = new MyMoto();
//        myMoto.refitDropbar();
//        myMoto.refitWindshield();
        DropbarRefit d = new DropbarRefit();
        WindshieldRefit w = new WindshieldRefit();
        myMoto.upgradeMoto(d);
        myMoto.upgradeMoto(w);

    }
}

类图：

经过上面代码改造后，如果我还想改装一个加热手把，那么不需要改源代码，只需要新创建一个类，通过传参的方式实现改装。实际上这是一种大家非常熟悉的方式，叫依赖注入。注入的方式还有构造器方式和 setter 方式。

构造器方式

public class MyMoto {

    private Refit refit;

    public MyMoto(Refit refit) {
        this.refit = refit;
    }
    public void upgradeMoto(){
        refit.refit();
    }

}

public class Test {
    public static void main(String[] args) {
        MyMoto myMoto = new MyMoto(new DropbarRefit());
        myMoto.upgradeMoto();

        MyMoto myMoto2 = new MyMoto(new WindshieldRefit());
        myMoto2.upgradeMoto();

    }
}

根据构造器方式注入，在调用时，每次都要创建实例。那么，如果 MyMoto 是全局单例，则我们就只能选择用 Setter 方式来注入:

public class MyMoto {

    private Refit refit;

    public void upgradeMoto(){
        refit.refit();
    }

    public Refit getRefit() {
        return refit;
    }

    public void setRefit(Refit refit) {
        this.refit = refit;
    }
}

public class Test {
    public static void main(String[] args) {
        MyMoto myMoto = new MyMoto();
        myMoto.setRefit(new DropbarRefit());
        myMoto.upgradeMoto();

        myMoto.setRefit(new WindshieldRefit());
        myMoto.upgradeMoto();

    }
}

类图：

大家要切记:以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求之后， 要面向接口编程，先顶层再细节来设计代码结构。

3.单一职责原则 （Simple Responsibility Principle）

定义：
单一职责(Simple Responsibility Pinciple，SRP) 是指不要存在多于一个导致类变更的原因。假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。

解决方法：
给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计， 可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一个 Class/Interface/Method 只负责一项职责。

比如说的摩托车，需要改装和保养，有时候偷懒会将这些方法写在一个接口里
代码：

public interface Refit {
    /**
     * 改装
     */
    void refit();

    /**
     * 保养
     */
    void maintain();
}

但其实，这是违反单一职责原则的。应该把改装和保养分离开来。拆成两个接口

public interface Refit {
    /**
     * 改装
     */
    void refit();
}

public interface Maintain {
    /**
     * 保养
     */
    void maintain();
}

在比如说，修改摩托车型号，颜色。有时都是放在一个方法中的。

private void modifyMotoInfo(String type,String color){ 
	type = "GT650";
	color = "white"; 
}

显然，上面的 modifyMotoInfo()方法中都承担了多个职责，既可以修改 type,也可以修改color，甚至更多，明显不符合单一职责。那么我们做如下修改，把这个方法拆成两个:

private void modifyMotoType(String type){
type = "GT650"; }
private void modifyMotoColor(String color){
color = "white"; }

这修改之后，开发起来简单，维护起来也容易。但是，我们在实际开发中会项目依赖，组合，聚合这些关系，还有还有项目的规模，周期，技术人员的水平，对进度的把控，很多类都不符合单一职责。 但是，我们在编写代码的过程，尽可能地让接口和方法保持单一职责，对我们项目后期的维护是有很大帮助的。

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

定义：
接口隔离原则(Interface Segregation Principle, ISP) 是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口时应当注意以下几点:

• 一个类对一类的依赖应该建立在最小的接口之上。
• 建立单一接口，不要建立庞大臃肿的接口。
• 尽量细化接口，接口中的方法尽量少(不是越少越好，一定要适度)。

接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性
和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。

下面我们来看一段代码， 写一个动物行为的抽象:

IAnimal 接口:

public interface IAnimal {
    void eat();
	void fly();
    void swim();
}

Bird 类实现:

public class Bird implements IAnimal {
    @Override
    public void eat() {}
    @Override
    public void fly() {}
    @Override
    public void swim() {}
}

Dog 类实现:

public class Dog implements IAnimal {
    @Override
    public void eat() {}
    @Override
    public void fly() {}
    @Override
    public void swim() {}
}

可以看出，Bird 的 swim()方法可能只能空着，Dog 的 fly()方法显然不可能的。这时候，我们针对 不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和 ISwimAnimal 接口，来看代码:

IEatAnimal 接口:

public interface IEatAnimal {
	void eat(); 
}

IFlyAnimal 接口:

public interface IFlyAnimal {
	void fly(); 
}

ISwimAnimal 接口:

public interface ISwimAnimal {
    void swim();
}

Dog 只实现 IEatAnimal 和 ISwimAnimal 接口:

public class Dog implements ISwimAnimal,IEatAnimal { 
	@Override
    public void eat() {}
    @Override
    public void swim() {}
}

类图的对比

5.迪米特法则 （Law of Demeter）

定义：
迪米特原则(Law of Demeter LoD) 是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则(Least Knowledge Principle,LKP)，尽量降低类与类之间的耦合。迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类， 而出现在方法体内部的类不属于朋友类。

学习软件设计原则，千万不能形成强迫症。碰到业务复杂的场景，我们需要随机应变。

6.里氏替换原则 （Liskov Substitution Principle）

定义：
里氏替换原则(Liskov Substitution Principle,LSP) 是指如果对每一个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义看上去还是比较抽象，我们重新理解一下，可以理解为一个软件实体如果适用一个父类的话， 那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。根据这个理解，我们总结一下:

引申含义:子类可以扩展父类的功能，但不能改变父类原有的功能。

1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2. 子类中可以增加自己特有的方法。
3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。
4. 当子类的方法实现父类的方法时(重写/重载或实现抽象方法)，方法的后置条件(即方法的输出/返回值)要比父类更严格或相等。

使用里氏替换原则有如下优点

1. 约束继承泛滥，开闭原则的一种体现。
2. 加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低
   需求变更时引入的风险。

现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道正方形是一个特殊的长方形，那么就可以创建一个长方形父类 Rectangle 类：

public class Rectangle {
    private long height;
    private long width;
    public long getHeight() {
        return height;
    }
    public void setHeight(long height) {
        this.height = height;
    }
    public long getWidth() {
        return width;
    }
    public void setWidth(long width) {
        this.width = width;
    }
}

创建正方形 Square 类继承长方形：

public class Square extends Rectangle {
    private long length;

    public long getLength() {
        return length;
    }

    public void setLength(long length) {
        this.length = length;
    }

    @Override
    public long getHeight() {
        return getLength();
    }

    @Override
    public void setHeight(long height) {
        setLength(height);
    }

    @Override
    public long getWidth() {
        return getLength();
    }

    @Override
    public void setWidth(long width) {
        setLength(width);
    }
}

在测试类中创建 resize()方法，根据逻辑长方形的宽应该大于等于高，我们让高一直自增，知道高等于宽变成正方形：

public static void resize(Rectangle rectangle){
        while(rectangle.getWidth()>=rectangle.getHeight()){
        rectangle.setHeight(rectangle.getHeight()+1);
        System.out.println("Width:"+rectangle.getWidth()+",Height:"+rectangle.getHeight());
        }
        System.out.println("Resize End,Width:"+rectangle.getWidth()+",Height:"+rectangle.getHeight());
}

测试代码：

public static void main(String[] args) {
	Rectangle rectangle = new Rectangle();
	rectangle.setWidth(20);
	rectangle.setHeight(10);
	resize(rectangle);
}

现在我们再来看下面的代码，把长方形Rectangle 替换成它的子类正方形 Square，修改测试代码：

public static void main(String[] args) {
	Square square = new Square();
	square.setLength(10);
	resize(square);
}

这时候我们运行的时候就出现了死循环，违背了里氏替换原则，将父类替换为子类后，程序运行结果没有达到预期。因此，我们的代码设计是存在一定风险的。里氏替换原则只存在父类与子类之间，约束继承泛滥。我们再来创建一个基于长方形与正方形共同的抽象四边形 Quadrangle 接口：

public interface QuadRangle {
	long getWidth();
	long getHeight();
}

修改长方形 Rectangle 类：

public class Rectangle implements QuadRangle {
	private long height;
	private long width;
	public long getHeight() {
		return height;
	}
	public void setHeight(long height) {
		this.height = height;
	}
	public long getWidth() {
		return width;
	}
	public void setWidth(long width) {
		this.width = width;
	}
}

修改正方形类 Square 类：

public class Square implements QuadRangle {
	private long length;
	public long getLength() {
		return length;
	}
	public void setLength(long length) {
		this.length = length;
	}
	public long getWidth() {
		return length;
	}
	public long getHeight() {
		return length;
	}
}

此时，如果我们把 resize()方法的参数换成四边形 Quadrangle 类，方法内部就会报错。因为正方形 Square 已经没有了 setWidth()和 setHeight()方法了。因此，为了约束继承泛滥，resize()的方法参数只能用 Rectangle 长方形。

7.合成复用原则 （Composite&Aggregate Reuse Principle）

定义

合成复用原则（Composite/Aggregate Reuse Principle,CARP） 是指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。

继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP模型。

以数据库操作为例，先来创建 DBConnection 类：

public class DBConnection {
	public String getConnection(){
		return "MySQL 数据库连接";
	}
}

创建 ProductDao 类：

public class ProductDao{
	private DBConnection dbConnection;
		public void setDbConnection(DBConnection dbConnection) {
		this.dbConnection = dbConnection;
	}
	public void addProduct(){
		String conn = dbConnection.getConnection();
		System.out.println("使用"+conn+"增加产品");
	}
}

这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection 还不是一种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生变化，数据库操作层要支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对 Oracle 数据库支持的方法。但是违背了开闭原则。其实，我们可以不必修改 Dao 的代码，将 DBConnection 修改为 abstract，来看代码：

public abstract class DBConnection {
	public abstract String getConnection();
}

然后，将 MySQL 的逻辑抽离：

public class MySQLConnection extends DBConnection {
	@Override
	public String getConnection() {
		return "MySQL 数据库连接";
	}
}

再创建 Oracle 支持的逻辑：

public class OracleConnection extends DBConnection {
	@Override
	public String getConnection() {
		return "Oracle 数据库连接";
	}
}

具体选择交给应用层

设计原则总结

学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。