设计模式的七大原则(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应该尽量的少用,要不耦合会非常严重,去看看优秀源码也是如此。可以思考思考使用单一职责原则,用类来划分多分支。

总结

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

你或许想:《去原作者写文章的地方

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论