“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。
直到 1990 年，软件工程界才开始研讨设计模式的话题。
1995年，“四人组”（Gang of Four，GoF）合作出版了《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）一书，在书籍中收录了 23 个设计模式，这是设 计模式领域里程碑的事件，导致了软件设计模式的突破。
直到今天，狭义的设计模式还是该书中所介绍的23种经典设计模式。

设计模式的概念

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、 代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提 高代码的可重用性、代码的可读性和代码的可靠性。

开闭原则由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。简单点说就是：一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。那么什么是软件实体呢？

这里的软件实体包括以下几个部分：

• 项目中划分出的模块
• 类与接口
• 方法

一个软件产品在她的生命周期内一般都会发生变化，开闭原则视为软件实体的未来事件而制定的对现行开发设计进 行约束的一个原则。

举个例子：以书店销售书籍为例：

public interface IBook { 
        
	public String getName();
	public int getPrice();
	public String getAuthor();
}

public class NovelBook implements IBook{ 
        
	private String name;
	private int price;
	private String author;

	public NovelBook(String name, int price, String author) { 
        
		this.name = name;
		this.price = price;
		this.author = author;
	}
	
	@Override
	public String getName() { 
        
		return this.name;
	}
	
	@Override
	public String getPrice() { 
        
		return this.price;
	}
	
	@Override
	public String getAuthor() { 
        
		return this.author;
	}
}

public class BookStroe { 
        
    private static ArrayList<IBook> bookList=new ArrayList<>();

    static { 
        
        bookList.add(new OffNovelBook("红楼梦", 9900, "曹雪芹"));
        bookList.add(new OffNovelBook("侠客行", 8900, "金庸"));
        bookList.add(new OffNovelBook("原则", 6900, "瑞达利欧"));
        bookList.add(new OffNovelBook("海贼王1", 4900, "尾田荣一郎"));
    }

    public static void main(String[] args) { 
        
        System.out.println("卖书的记录如下----------------------");
        for (IBook book : bookList) { 
        
            System.out.println("书籍名称："+book.getName()+"\t\t作者："+book.getAuthor()+"\t\t价格：￥"+book.getPrice()/100.0+"元");
        }
    }
}

运行结果：

项目上线，书籍能正常销售了。但是现在双十一要到了，书店决定要来一波促销活动，70元以上的书籍9折销售， 70元以下的书籍8折销售。对该项目来说，这就是一个变化，我们该怎么应该如下变化呢？有3中解决方法：

（1）修改接口

在IBook接口里新增getOffPrice()方法，专门用于进行打折，所有的实现类都实现该方法。但这样修改的后果就 是，实现类NovelBook要修改，书店类BookStore中的main方法也要修改，同时，IBook作为接口应该是稳定且可靠的，不应该经常发生变化，因此，该方案被否定。

（2）修改实现类

修改NovelBook类中的方法，直接在getPrice()方法中实现打折处理，这个方法可以是可以，但如果采购书籍的人员要看价格怎么办，由于该方法已经进行了打折处理，因此采购人员看到的也是打折后的价格，会因信息不对称出现决策失误的情况。因此，该方案也不是一个最优的方案。

（3）通过扩展实现变化

增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是BookStore中static静态块中）通过 OffNovelBook类产生新的对象，完成业务变化对系统的最小开发。这样修改也少，风险也小。

public class OffNovelBook extends NovelBook{ 
        

    public OffNovelBook(String name, int price, String author) { 
        
        super(name, price, author);
    }

    @Override
    public int getPrice() { 
        
        int sellPrice=super.getPrice();
        int offPrice=0;
        if(sellPrice>7000){ 
        
            offPrice=sellPrice*90/100;
        }else{ 
        
            offPrice=sellPrice*80/100;
        }
        return offPrice;
    }
}

public class BookStroe { 
        
    private static ArrayList<IBook> bookList=new ArrayList<>();

    static { 
        
        bookList.add(new OffNovelBook("红楼梦", 9900, "曹雪芹"));
        bookList.add(new OffNovelBook("侠客行", 8900, "金庸 "));
        bookList.add(new OffNovelBook("原则", 6900, "瑞·达利欧"));
        bookList.add(new OffNovelBook("海贼王1", 4900, "尾田荣一郎"));
    }

    public static void main(String[] args) { 
        
        System.out.println("书店卖书的记录如下----------------------");
        for (IBook book : bookList) { 
        
            System.out.println("书籍名称："+book.getName()+"\t\t作者："+book.getAuthor()+"\t\t价格：￥"+book.getPrice()/100.0+"元");
        }
    }
}

运行结果：

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。 具体来说，其作用如下。

1. 对软件测试的影响

软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运 行。

2. 可以提高代码的可复用性

粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。

3. 可以提高软件的可维护性

遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
2. 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

举一个例子：

public interface IPhone { 
        
	//拨通电话
	public void dial(String phoneNumber);
	//通话
	public void chat(Object o);
	//通话完毕，挂断电话
	public void hangup();
}

以上是符合单一职责原则的吗？说白了是一个接口只负责一件事情吗？是只有一个原因引起变化么？

好像不是哦！

其实他负责了两个内容：1、协议管理，2、数据传送。

dial()和hangup()两个方法实现的是协议管理；chat()方法负责的是数据的传送。那么协议的改变可能引起接口或者 实现类的变化；同样数据传送（电话不仅可以打电话，还能上网）的变化也可能会引起接口或实现类的变化。两个 原因都能引起变化，而两个职责直接是互不影响的，所以可以考虑拆分为两个接口。

public interface IPhone { 
        

}

public interface IConnectionManger extends IPhone{ 
        
	//拨通电话
    void dial(String phoneNumber);
    //通话完毕，挂断电话
    void hangup();
}

public interface IDataTransfer { 
        
	//通话
    void chat(Object obj);
}

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

• 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
• 提高类的可读性。复杂性降低，自然其可读性会提高。
• 提高系统的可维护性。可读性提高，那自然更容易维护了。
• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其 他功能的影响。

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

PS：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

但是原则是死的，人是活的。所以有些时候我们可以为了效率，牺牲一定的原则性。

这是一个爱恨纠葛的父子关系的故事。该原则可以理解为：子类可以替换父类。

父子类实在我们学习继承这个知识点的时候学习到的概念。我们先来回忆一下继承的优缺点：

优点：

1. 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
2. 提高代码的重用性；
3. 提高代码的可扩展性，子类可形似于父类，但异于父类，保留了自己独特的个性；其实很多开源框架的扩展都 是通过继承父类实现的。
4. 提供产品或者项目的开放性。

缺点：

1. 继承是侵入性的，只要继承就必须拥有父类的所有方法和属性；
2. 降低了代码的灵活性。子类必须拥有父类的属性和方法，让子类中多了约束；
3. 增加了耦合，当父类的常量、变量或者方法被修改了，需要考虑子类的修改，所以一旦父类有了变动，很可能会造成非常糟糕的结果，要重构大量的代码。

java中使用extends关键字来实现继承，采用的是单一继承的规则，C++则采用了多重继承的规则，即一个子类可 以继承多个父类。从整体上上看，利大于弊，怎么才能更大的发挥“利”的作用呢？

解决方案就是引入里氏替换原则。什么是里氏替换原则呢？

该原则有两个定义:

• 第一种：如果每一个类型S的对象o1，都有一个类型T的对象o2，在以T定义的所有程序P中将所有的对象o2都替 换为o1，而程序P的行为没有发生变化，那么S是T的子类。
• 第二种：所有引用基类的地方必须能透明地使用其子类对象。

第一个定义看起来有点难，其实意思就是说:在一个程序中，如果可以将一个类T的对象全部替换为另一个类S的对 象，而程序的行为没有发生变化，那么S是T的子类。

第二个定义明显要比第一个定义更容易理解，非常的清晰明确。通俗地讲，就是任何一个使用父类的地方，你都可 以把它替换成它的子类，而不会发生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过 来就不行了，有子类出现的地方，父类未必可以替换。

里氏替换原则是继承复用的基石，它为良好的继承定义了一个规范，定义中包含了4层含义：

1. 子类必须完全实现父类的方法。

我们以前做过的项目中，经常定义一个接口或者抽象类，然后编码实现，调用类则直接传入接口或者抽象 类，其实这就是已经在使用历史替换原则了。

举个栗子：是不是很多人玩过CS(真人版cs或者游戏都算，没玩过也没关系，他就是一个比较火爆的第一人称射击游戏。你就知道用到了很多枪就行了)。

//枪的抽象类
public abstract class AbstacTGun { 
        
    //射击
    public abstract void shoot();
}

//手枪：携带方便但是射程短
public class Handgan extends AbstacTGun{ 
        
    @Override
    public void shoot() { 
        
        System.out.println("手枪射击------------");
    }
}

//步枪：威力大射程远
public class Rifle extends AbstacTGun{ 
        
    @Override
    public void shoot() { 
        
        System.out.println("步枪射击------------");
    }
}

//机枪：威力更大连续发射
public class MachineGun extends AbstacTGun{ 
        
    @Override
    public void shoot() { 
        
        System.out.println("机枪射击------------");
    }
}

//士兵：使用枪支
public class Solider { 
        
    //士兵使用的枪
    private AbstacTGun gun;
    //通过set方法给士兵配枪
    public void setGun(AbstacTGun gun) { 
        
        this.gun = gun;
    }
    public void killEnemy(){ 
        
        System.out.println("士兵杀敌：");
        gun.shoot();
    }
}

public class Client { 
        

    public static void main1(String[] args) { 
        
        //定义一个士兵
        Solider xunSanDuo=new Solider();
        //给许三多配枪
        xunSanDuo.setGun(new Rifle());
        xunSanDuo.killEnemy();
    }
}

运行结果：

在场景类中，给士兵配枪的时候可以是三种枪中的任何一个，其实士兵类可以不用知道是哪种的枪（子类） 被传入。

PS：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或者接口，说明类的设计违背了里氏替换原则。

2. 子类中可以增加自己特有的方法。

类都有自己的属性和方法，子类当然也不例外。除了从父类继承过来的，可以有自己独有的内容。为什么要 单独列出来，是因为里氏替换原则是不可以反过来用的。也就是子类出现的地方，父类未必可以胜任。 我们继续上面的案例：步枪下面还有几个比较知名的种类：例如AK47和AUG狙击步枪。

public class AUG extends Rifle{ 
        
    //狙击枪都携带了精准的望远镜
    public void zoomOut(){ 
        
        System.out.println("通过望远镜观察敌人：");
    }

    @Override
    public void shoot() { 
        
        System.out.println("AUG射击-----------");
    }
}

//狙击手
public class Snipper extends Solider{ 
        

    public void killEnemy(AUG aug) { 
        
        //先观察
        aug.zoomOut();
        aug.shoot();
    }
}

//场景类：
public class Client { 
        

    public static void main(String[] args) { 
        
        //定义一个狙击手
        Snipper hanGuang=new Snipper();
        //配枪
        hanGuang.setGun(new AUG());
        hanGuang.killEnemy();
    }
    
}

场景类中我们可以直接使用子类，狙击手是依赖枪支的，别说换一个型号的枪，就是同一个型号的枪都会影 响射击，所以这里直接传递子类。

public class Client { 
        

    public static void main(String[] args) { 
        
        //定义一个狙击手
        Snipper hanGuang=new Snipper();
        //配枪
        hanGuang.setGun((AUG)new Rifle());
        hanGuang.killEnemy();
    }
}

会在运行的时候抛出异常，这就是我们经常说的额向下转型是不安全的。从里氏替换原则来看：子类出现的 地方，父类未必可以出现。

3. 当子类覆盖或实现父类的方法时，方法的输入参数（方法的形参）要比父类方法的输入参数更宽松。

public class LSP { 
        
    //当子类覆盖或者实现父类的方法时，方法的输入参数要比父类的方法输入的参数更宽松
    class Parent{ 
        
        public void fun(HashMap map){ 
        
            System.out.println("父类被执行....");
        }
    }
    class Sub extends Parent{ 
        
        public void fun(Map map){ 
        
            System.out.println("子类被执行....");
        }
    }

    public static void main(String[] args) { 
        
        System.out.println("父类运行的结果：");
        LSP lsp=new LSP();
        Parent a=lsp.new Parent();
        HashMap<Object,Object> hashMap=new HashMap<>();
        a.fun(hashMap);
        //父类存在的地方可以用子类匪患
        //子类替换父类
        System.out.println("子类替换父类运行的结果：");
        Sub b=lsp.new Sub();
        b.fun(hashMap);
    }
}

ps:这里子类并非重写了父类的方法，而是重载了父类的方法。因为子类和父类的方法的输入参数是不同的。 子类方法的参数Map比父类方法的参数HashMap的范围要大，所以当参数输入为HashMap类型时，只会执行父类的方 法，不会执行父类的重载方法。这符合里氏替换原则。

4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。