设计模式的七大原则(1) --单一职责原则

前言

最近工作中备受打击，之前设计的很多程序都被老大否决，需要重构，让我好好看看设计模式。之前对这一块内容的确不怎么重视，感觉枯燥无聊又派不上用场。后来沉下心来研究了一番...

我靠，原来如此，之前写代码的时候怎么这么傻逼，很多问题其实在一开始设计的时候就能避免。之前写的都是些什么鬼。

我们踩过的坑，历代前辈们也踩过。可想而知，通他们多年的踩坑填坑经验后，所总结出来的23种设计模式是多么的宝贵，就是我们的“ONE PIECE” 啊。如果掌握了这个内容，对今后无论是工作中还是面试都非常重要。因此下定决心，一定要熟练掌握这块内容。记录学习过程，供自己复习也供大家一起学习。

为什么要学习设计模式的目的

在前言中我们已经大致说明，我们总结一下，一个良好的程序应该满足一下六点要求：

1. 可复用性：尽量能重用方法，比如说提取某种工具类。
2. 可读性：编程具备规范性，阅读起来不困难。
3. 可扩展性：当你写好的程序需要添加一个新功能的时候，不能说:不行！非要添加的话我要重构代码。
4. 稳定性：尽可能少的bug。
5. 高内聚：每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码。
6. 低耦合：并且模块之间联系越复杂耦合度越低，就不会牵一发而动全身。否则模块A的bug甚至会导致模块B无法运行

这是多代前辈们总结出来的编程经验，如果我们的程序没有以上特点，就会出现很多BUG。我们要站在巨人的肩膀上。尽量多学习多总结，避免犯“古人”们常犯的错误。

设计模式的作用就出来了，设计模式的目的就是为了让我们的程序具备以上六点特性。

设计模式常用的七大原则

在学习设计模式之前，为了不让设计模式显得很模式，我们还必须了解一个东西，那就是程序设计七大原则（很多地方说的是六大原则，但还有一个合成复用原则也值得提出来）。

这些原则是指导模式的规则，我会给一些原则附上一个例子，来说明这个原则所要表达的意思，注意，原则是死的，人是活的，所以并不是要你完完全全遵守这些规则，否则为何数据库会有逆范式，只是在可能的情况下，请尽量遵守。

七大原则分别是：

1. 单一职责原则（Single Responsibility Principle）
2. 接口隔离原则（Interface Segregation Principle）
3. 依赖倒置原则（Dependence Inversion Principle）
4. 里氏替换原则（Liskov Substitution Principle）
5. 开闭原则（Open Close Principle）
6. 迪米特法则（Law Of Demeter）
7. 合成复用原则（Composite/Aggregate Reuse Principle CARP）

单一职责原则

看名字就能知道，我们设计的类要尽可能的只负责一项职责。比说说A类只负责A功能，B类只负责B功能，不要A类既负责A功能又负责B功能。

为什么要这样设计？

当A功能需要更新，那么就得去修改A类。如果此时A还负责B功能，就很有可能修出BUG后导致B功能的正常使用。或者说，想实现B功能却调用的A功能的接口，这样会导致程序运行混乱。总结以下几点：

1. 降低类的复杂度，一个类只负责一项职责。
2. 提高类的可读性，可维护性。
3. 降低变更引起的风险。
4. 通常情况下，我们应当遵守单一职责原则，只要逻辑足够简单，才可以在代码级别违反单一职责原则：也就是说类中的方法数量足够少，可以在方法级别保持单一职责原则。下述代码将会说明。

例如以下代码：

public class SingleResponsibility1 {
    public static void main(String args[]) throws IOException {
        Computer computer = new Computer();
        computer.add();
    }

}
//读取配置文件和计算
class Computer{
    public int add() throws NumberFormatException, IOException {
        File file = new File("D:/data.txt");
        BufferedReader br = new BufferedReader(new FileReader(file));
        int a = Integer.valueOf(br.readLine());
        int b = Integer.valueOf(br.readLine());
        return a+b;
    }
}

在这个Computer类中有一个add方法，负责读取配置文件数字，然后再进行相加。

这个类很明显违反了单一职责原则，一个类既负责了读取文件，又负责算数。大家考虑一下这样设计有没有什么问题？

问题诸多，提高代码可维护性，报错不好定位，功能耦合。。。

来看看更新后的代码是什么样子的：

public class SingleResponsibility2 {
    public static void main(String args[]) throws IOException {
        readFile readFile = new readFile();
        readFile.read("D:/data.txt");
        Computer2 computer = new Computer2();
        computer.add(readFile.getA(),readFile.getB());
    }

}
//计算
class Computer2 {
    public int add(int a, int b){
        return a + b;
    }
}
//读取配置文件
class readFile {
    private int a;
    private int b;

    public void read(String path) throws IOException {
        File file = new File(path);
        BufferedReader br = new BufferedReader(new FileReader(file));
        a = Integer.valueOf(br.readLine());
        b = Integer.valueOf(br.readLine());
    }

    public int getA() {
        return a;
    }

    public int getB() {
        return b;
    }
}

通过这样修改代码，我们实现了单一职责原则。

这样就万无一失了吗？

当然有时候也不见得，因为如果我们的代码足够简单，这样设计会提供编写代码的成本。并且同时还要修改客户端代码。

我们再来看看下面的代码：

public class SingleResponsibility3 {
    public static void main(String args[]) throws IOException {
        Computer3 computer = new Computer3();
        computer.read("D:/data.txt");
        computer.add(computer.getA(),computer.getB());
    }

}
//负责读取配置文件，并且负责计算
class Computer3 {
    private int a;
    private int b;

    public void read(String path) throws IOException {
        BufferedReader br = new BufferedReader(new FileReader(path));
        a = Integer.valueOf(br.readLine());
        b = Integer.valueOf(br.readLine());
    }

    public int getA() {
        return a;
    }

    public int getB() {
        return b;
    }

    public int add(int a, int b){
        return a + b;
    }
}

当然这个只是示例代码，在真正的开发环境也不可能这样用。我举这个例子只是想说明如果一个类的方法很少功能逻辑比较简单。如我们写的Computer类，只负责读取两个数，然后相加。

这样简单的类其实就可以在代码级别违反单一职责原则：也就是说类中的方法数量足够少，可以在方法级别保持单一职责原则。

还是那句话：人是活的，原则是死的。

一个优秀的代码if else应该尽量的少用，要不耦合会非常严重，去看看优秀源码也是如此。可以思考思考使用单一职责原则，用类来划分多分支。

总结

今天就到这里，一个一个慢慢吃透，一天进步一点。下一篇我们来看接口隔离原则。