六大原则

单一职责原则

定义：就一个类而言，应该仅有一个引起它变化的原因。

其实字面意思就已经表达的比较明确，单一，也就是干尽量少的事情。在HDU中可以对耦合和内聚程度的评判有一定的了解。

什么叫做少，其实很难有一个标准。但是在Android的MVC框架中，Activity既作为View，又起着Controller的作用的时候是否显得会很臃肿呢？他需要进行页面的刷新，网络处理，消息处理等等，写起来容易，但是在我们进行维护的时候，是不是会很头疼呢，这就是单一职责原则的对应所在了。

开放封闭原则

定义：类，模块，函数等应该是可以扩展的，但是不可以修改。

在日常的项目开发中，需求一直是处于一个变动的状态，但是这同样也会成为项目开发的壁垒，如果你的Bean今天是一只猫，明天就需要是一只狗呢？重新打补丁吗？显然是一个很不合适的做法。而开放封闭原则，解决的就是这一类问题。不论是猫，还是狗，他们总会有相同的特征，抽象化也就是这个原则实现的基础。

// 定义一个动物抽象类
public abstract class Animal {
    abstract void do();
}
 
// 猫实现抽象方法
class Cat extends Animal {
    @Override
    void do() {
        System.out.println("喵");
    }
}
 
// 狗实现抽象方法
class Dog extends Animal {
    @Override
    void do() {
        System.out.println("汪");
    }
}

里氏替换原则

定义：所有引用基类（一般来说都是抽象类或接口）的地方必须能透明的使用其子类的对象。

定义的具体含义就是将一个基类对象替换成其子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

想来直接看定义可能有点难以理解，接下来就用代码来具体实现里氏替换原则了。

/**
 * 基于里氏替换原则实现
 */
class Manage1 {
    private Animal animal;
 
    public void setAnimal(Animal animal) {
        this.animal = animal;
    }
 
    void getSound() {
        animal.do();
    }
}

/**
 * 使用子类实现
 */
class Manage2 {
    private Cat cat;
 
    public void setAnimal(Cat cat) {
        this.cat = cat;
    }
 
    void getSound() {
        cat.do();
    }
}

以上基于两种写法，给予读者评判，如果使用Manage2，如果我们希望获得Dog的声音，那么就需要重新实现Manager3，然后差异就是只是把Cat置换成Dog。而Manage1很好的解决了这个问题，因为不论是Cat还是Dog都是Animal的子类。

依赖倒置原则

定义：高层模块不应该依赖底层模块，两者都应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

两个概念：

抽象/高层模块：接口或者抽象类，一般只定义了有什么操作，但是没有具体实现。
细节/底层模块：实现接口或者继承抽象类而产生的，一般来说就是我们通过new产生出来的对象。

这里的代码与开闭原则、里氏替换原则一致，详细见于上文。

Dog和Cat作为Animal的子类，对于do()函数，父类只是一个抽象的方法，而子类完成了具体的实现。而当类Manage1希望与类Cat发生关联时，就是通过类Animal来完成，好处就是Manage1不再关注了类Cat、Dog的具体实现。

迪米特原则

定义：一个软件实体应当少的与其他实体发生相互作用。

其实和上面的内容差不多，同样都是为了降低耦合程度，直接用Demo证明就清楚明了了。

电话网络形式：

打电话的人 --> 接电话的人
打电话的人 --> 中间服务商转接 --> 接电话的人

第一种已经被时代抛弃了，虽然我们并不知觉，但是第一种电话网络模式，如果用在现代社会，那么带来的后果就是你再也看不见太阳了，头顶密密麻麻的电话线，更何况那是座机互联的时代，能够靠电话线来解决，但是这个时代呢？移动互联的时代呢，不能再靠着电话线来解决问题，而是中间商的介入就改变了这个现状。

（1）第一种电话网络模式

/**
 * 打电话的人
 */
class Call {
    private Receiver receiver;
 
    public void setReceicer(Receiver receiver) {
        this.receiver = receiver;
    }
 
    public void call() {
        receiver.receive();
    }
}

/**
 * 接电话的人
 */
class  Receiver{
    
    private String number;
    Receiver(String number){
         this.number = number;
    }
    
    public void receive() {
        System.out.println("接通电话");
    }
}

class Main{
    public static void main(String[] args) {
        Call call = new Call();
        call.setReceicer(new Receiver("电话号码"));
        call.call();
    }
}

代码虽然看着很轻松，但是折射到现实情况的时候，每一个拨打电话和接收电话的人之间都等于连接了一条电话线。

（2）第二种电话网络模式

/**
 * 转接
 */
public abstract class Manager {
    abstract void link();
}
 
/**
 * 打电话的人
 */
class Call {
    private Manager manager;
    
    public void setManager(Manager manager) {
        this.manager = manager;
    }
 
    public void call() {
        manager.link();
    }
}
 
/**
 * 接电话的人
 */
class  Receiver{
    
    private String number;
    Receiver(String number){
         this.number = number;
    }
    
    public void receive() {
        System.out.println("接通电话");
    }
}

class CMCC extends Manager {
    private String number;
  
    CMCC(String number){
      this.number = number;
    }

    public void link() {
        System.out.println("连接接电话的人");
        Receiver receiver = new Receiver();
        receiver.receive();
    }
}

class Main{
    public static void main(String[] args) {
        Call call = new Call();
        call.setManager(new CMCC("电话号码"));
        call.call();
    }
}

这个时候两个实体通过加入中间商的形式降低了耦合度。也就像我们生活中的各个电话厂商，你不会因为厂商不同而担心不能拨通电话，因为中间的处理过程厂商会帮你解决。

接口隔离原则

定义：一个类对另一个类的依赖应该建立在最小的接口上

一个接口内要实现的函数数量可控，有那么一点像数据库里的第一范式。让我们从Demo看看使用原则的与否的不同之处。

正常实现

// 特征
interface Character {
    void look();
    void nature();
}

class Dog implements Character{
    @Override
    void look() {
        System.out.println("能看");
    }
    @Override
    void nature() {
        System.out.println("淘气");
    }
}

基于接口隔离原则实现

// 外观
interface Facade {
     void look();
}
// 内在
interface Inherent {
    void nature();
}

class Dog implements Inherent{
    @Override
    void nature() {
        System.out.println("淘气");
    }
}

几个常用的设计模式

单例模式

定义：保证一个类仅有一个实例，并提供用于一个访问它的全局访问点。

四种写法及其优缺点

(1) 饿汉模式

public class Singleton {
    private static Singleton instance = new Singleton();
    private Singleton(){}
    public static Singleton getInstance(){
        return instance;
    }
}

在类加载时就已经完成了初始化。

优点：1. 保障了线程同步的问题；2. 获取对象的效率高。

缺点：1. 降低了类加载时速度；2. 如果一直不使用，会内存的浪费。

(2) 懒汉模式

线程不安全

public class Singleton {
    private static Singleton instance;
    private Singleton(){}
    public static Singleton getInstance(){
        if(instance == null) instance = new Singleton();
        return instance;
    }
}

缺点：存在线程同步问题

线程安全

public class Singleton {
    private static Singleton instance;
    private Singleton(){}
    public static synchronized Singleton getInstance(){
        if(instance == null) instance = new Singleton();
        return instance;
    }
}

缺点：每一次都需要同步，存在一定的开销问题。

懒汉模式相较于饿汉模式，不会存在不使用的问题。虽然不再在加载时消耗资源，但是实例化时同样会有一定的时间开销。

(3) 双重检查模式/DCL

public class Singleton {
    private volatile static Singleton instance;
    private Singleton(){}
    public static  Singleton getInstance(){
        if(instance == null) {
            synchronized (Singleton.class){
                if(instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

使用volatile关键词是对正确性的一种保障。

相较于懒汉模式而言，这又是一种升级。因为不在将synchronized套在了函数上，也就不会每次调用都对整个函数同步了，提高了资源的利用率。但是同样存在失效的情况。

存在失效的原因（对使用volatile的解释）

因为JVM的加载顺序是一个无序状态，他可能进行过指令优化的重排操作，那这种情况就是我们不可控制的，而volatile起着不被忽略的作用，保证了我们的instance不被指令重排。这也就是他的优化方法。

(4) 静态内部类单例模式

public class Singleton {
    private Singleton(){}
    public static Singleton getInstance() {
        return SingletonHolder.instance;
    }

    private static class SingletonHolder {
        private volatile static Singleton instance = new Singleton();
    }
}

这是最常用的方法，也是对DCL的一种升级。

优缺点和前面都差不多，就不再复述了。

模式分析

使用这个模式时说明系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器，或者需要考虑资源消耗太大而只允许创建一个对象。

缺点：

单例类的扩展有很大的困难
单例类的职责过重，在一定程度上违背了“单一职责原则”。
如果实例化的对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致对象状态的丢失

工厂模式

工厂模式分为三种：

（1）简单工厂模式

（2）工厂方法模式

（3）抽象工厂模式

所以接下来将从这三种模式中进行分析和比较。

简单工厂模式

写法

/**
 * 工厂类
 */
public class Factory {
    public static Product createProduct(String type){
        Product product = null;
        switch (type){
            case "鸡翅":
                product = new ChickenWing();
                break;
            case "汉堡":
                product = new Hamburger();
                break;
        }
        return product;
    }
}

/**
 * 抽象产品类
 */
public abstract class Product {
    public abstract void use();
}

/**
 * 具体产品类
 */
public class Hamburger extends Product {
    @Override
    public void use() {
        System.out.println("汉堡制作完成");
    }
}

public class ChickenWing extends Product {
    @Override
    public void use() {
        System.out.println("鸡翅制作完成");
    }
}

模式分析

将类的创建细节与使用者隔离，使用者只需要知道对应的参数，将其送入工厂中即可完成创建。就比如我想吃汉堡了，那我就告诉工厂，汉堡这个关键参数，那么工厂就会将汉堡这个好吃的家伙送给我。但是这个工厂要注意，他可以制造鞋子、袜子、零食。。。你所能想到的想要找他做的他都得学会。

缺点：

工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。

工厂方法模式

写法

/**
 * 抽象工厂类
 */
public abstract class Factory {
    public abstract <T extends Product> T  createProduct(Class<T> clazz);
}

/**
 * 具体工厂类
 */
public class KFC extends Factory {
    @Override
    public <T extends Product> T createProduct(Class<T> clazz) {
        Product product = null;
        try{
            product = (Product) Class.forName(clazz.getName()).newInstance();
        }catch (Exception e){
            e.printStackTrace();
        }
        return (T) product;
    }
}

模式分析

与简单工厂模式不一样的地方在于我们创建了专门的工厂，也就是说比如我们今天想吃汉堡，但是同时有肯德基、麦当劳、汉堡王等好几家公司可以生产，就轮到了我们选择谁来进行制作的问题了。但是这样的模式依旧存在一个问题，那就是我们需要专门跑到肯德基、麦当劳又或者是汉堡王的门店去，我们才能点餐。

缺点：

在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。

抽象工厂模式

写法

public class FactoryProducer {
   public static AbstractFactory getFactory(String factory){
      if(factory.equalsIgnoreCase("KFC")){
         return new KFC();
      } 
      return null;
   }
}

模式分析

再次与上述的工厂方法模式进行比较，这次我们不需要再到肯德基门店去就可以买汉堡了，为什么呢？因为我们现在手上有饿了么，有美团了。我在搜索栏中输入了肯德基，他就告诉我了有这样的一个工厂，这样我们就能远程遥控获得这样的一个我们想要的油炸食品了。

缺点：

在添加新的产品对象时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改

观察者模式

写法

/**
 * 抽象观察者类
 */
public interface IObserver {
    void update(String message);
}

/**
 * 抽象主题类
 */
public interface ISubject {
    void add(IObserver observer);
    void remove(IObserver observer);
    void notify(String message);
}

/**
 * 具体观察者类
 */
public class Observer implements IObserver {
    @Override
    public void update(String message) {
        System.out.println(message);
    }
}

/**
 * 具体主题类
 */
public class Subject implements ISubject {
    List<IObserver> list = new ArrayList<>();

    @Override
    public void add(IObserver observer) {
        list.add(observer);
    }

    @Override
    public void remove(IObserver observer) {
        list.remove(observer);
    }

    @Override
    public void notify(String message) {
        for(IObserver observer: list){
            observer.update(message);
        }
    }
}

模式分析

抛去模式中的接口类，就剩下了主题和观察者，这个模式的发生就是基于主题的变更与对观察者的通知。

这个模式在我的 helper 工具包中也有使用，就是基于对系统服务的监听，发现变化后，对订阅此变化的观察者们发出通知，并由观察者自己作出相应的动作。

缺点：

一个主题存在多个观察者，而通知的方式是通过轮询，这样的通知会有一定的时间消耗。
如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。

代理模式

写法

静态代理

/**
 * 抽象主题类
 * 中心主题，买东西。
 */
public interface IShop {
    void buy();
}

/**
 * 真实主题类
 * 也就是我们购买者
 */
public class Person implements IShop {
    @Override
    public void buy() {
        System.out.println("购买");
    }
}

/**
 * 代理类
 * 持有被代理者
 */
public class StaticPurchase implements IShop {
    private IShop shop;

    WhoBuy(IShop shop){
        this.shop = shop;
    }
    @Override
    public void buy() {
        shop.buy();
    }
}

动态代理

/**
 * 动态代理类
 */
public class DynamicPurchase implements InvocationHandler {
    private Object object;
    DynamicPurchase(Object object){
        this.object = object;
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = method.invoke(object, args);
        if(method.getName().equals("buy")){
            System.out.println("买上");
        }
        return result;
    }
}

/**
 * 客户端类
 */
public class User {
    public static void main(String[] args) {
        Shop person = new Person();
        DynamicPurchase dynamicPurchase = new DynamicPurchase(person);
        ClassLoader loader = person.getClass().getClassLoader();
        Shop purchase = (Shop) Proxy.newProxyInstance(loader, new Class[]{Shop.class}, dynamicPurchase);
        purchase.buy();
    }
}

模式分析

你可以看到上述文中和之前出现了不一样的地方，就是分为了两份代码，也就是动态代理和静态代理。那么就出现了这样的一个问题，何为静，何为动？

我们拿身边的代购举例，分为两种：

静就相当于我们需要找到专门的代理商，就是你微信里加的好友，你专门找到了他，然后跟他说想买Dior745，这样等他出国时就会帮你去买了。
动就是你只需要知道自己想要买Dior745，但是你这个时候手头没有静中的代理商，那你就找了淘宝，你只用知道自己想要的，不用再去思考代理商的问题了。也就是我们上文中所使用到的Proxy的代理技术。

缺点：

1.由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2. 实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

适配器模式

类适配器：

对象适配器：

写法

类适配器

public interface MP4{
    void play();
}

public class MP4Player implements MP4{
    public void play(){
        // doSomething
    }
}

public interface Player{
      void action();
}

public class Adapter extends MP4Player implements Player{
    public void action(){
        play();
    }
}

对象适配器

public class PlayerAdapter implements Player{
    public MP4 mp4;
    
    public PlayerAdapter (MP4 mp4){
        this.mp4 = mp4;
    }     

    public void action(){
        if(mp4!= null){
             mp4.play();
        }
    }
}

模式分析

适配器模式简单来说就是为两个互不兼容的两者提供了合作的桥梁。

想一想我们在Android中使用的RecyclerView中为了进行数据的适配是不是都会加上一个Adapter，因为我们从网络获取的数据Bean是无法直接和XML文件中的每个View需要填充的数据项进行对应的。而适配器就是将两者进行了沟通协作。

类适配器模式和对象适配器模式的区别是什么？

类适配器使用了继承的方式来完成、对象适配器使用了依赖的关系来完成任务。拿代码来说的话就是类适配器继承了MP4Player，而对象适配器依赖就是MP4这个接口类的使用。

缺点

类适配器模式 对于Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，而且目标抽象类只能为抽象类，不能为具体类，其使用有一定的局限性，不能将一个适配者类和它的子类都适配到目标接口。
对象适配器模式 与类适配器模式相比，要想置换适配者类的方法就不容易。如果一定要置换掉适配者类的一个或多个方法，就只好先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂。

策略模式

写法

/**
 * 上下文
 * 根据传入策略给出解决方法
 */
public class Context {
    private Strategy strategy;
    Context(Strategy strategy){
        this.strategy = strategy;
    }

    void solve(){
        strategy.solve();
    }
}

/**
 * 两种策略方法
 * 1. 普通用户
 * 2. Vip用户
 */
public class CustomStrategy implements Strategy {
    @Override
    public void solve() {
        System.out.println("普通用户");
    }
}

public class VipCustomStrategy implements Strategy {
    @Override
    public void solve() {
        System.out.println("Vip用户");
    }
}

/**
 * 抽象策略角色
 */
public interface Strategy {
    void solve();
}

模式分析

在掘金平台上看到最多的模式，没有之一。那我们是如何通过策略模式来干掉我们日常开发中的if-else的呢？

就拿上面的代码来说好了，如果使用if-else来完成任务。

if (level == "普通用户") {
    // ...
}else if (level == "Vip用户") {
    // ...
}

显然的很麻烦，而且会随着逻辑的复杂化而繁琐起来，就比如我今天Vip用户要分等级了，白银应该9折，黄金8折。。。。还ok，在Vip用户里继续加入if-else，第二天产品经理说要白银有一、二、三段了。你是不是想砍死你的产品经理了？？

而策略模式去完成的时候只是多了一个或者多个类，虽然类增多了，但是从至少让我们的代码从屎山变成了一堆堆屎。

缺点：

客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
策略模式将造成产生很多策略类。

参考文献

看懂UML类图和时序图

设计模式的十八般武艺

六大原则

单一职责原则

开放封闭原则

里氏替换原则

依赖倒置原则

迪米特原则

接口隔离原则

几个常用的设计模式

单例模式

四种写法及其优缺点

模式分析

工厂模式

简单工厂模式

写法

模式分析

工厂方法模式

写法

模式分析

抽象工厂模式

写法

模式分析

观察者模式

写法

模式分析

代理模式

写法

模式分析

适配器模式

写法

模式分析

策略模式

写法

模式分析

参考文献