面向对象设计原则——单一职责原则（SRP）

面向对象设计原则——单一职责原则（SRP）

tags:设计模式

The single responsiblility principle states that every object should have a single responsibility,and that responsibility should be entirely encapsulated by the ckass.All its services should be narrowly aliged with that responsibility.

单一职责原则简而言之就是每个类只担任一个职责,即每个类只有一个引起它变化的原因

实际情况下,当一个类的职责越多,那么它不稳定的概率越大,因为影响它的因素太多,导致其经常被修改,以至于成为最不稳定的几个类.

开发人员经常一不小心就让自己写的类身兼数职了,但是考虑到日后维护的需要,建议要尽量坚持单一职责原则,目标是让永恒的变化尽可能的少影响我们的类.

下面分析一个示例:

有一个接口,名称为:DataHandler,它完成数据的处理,这个处理通常分为三个操作:读取,格式化,写入目标环境.我们设计时有两种方法.

Data:抽象的原数据
Target:抽象的目标数据
Source:抽象的数据源

第一种,分割职责:

class interface Reader{
    Data read();
}
class interface Writer{
    void write(Data data);
}
class interface DataFormatter{
    Target format(Source source)
}
class interface DataHandler extends Reader,Writer,DataFormatter{}

第二种,未分割职责:

class interface DataHandler{
    Data read();
    void write(Data data);
    Target format(Source source)
}

未分割的角色的设计只有三个方法是–read,format,write它们正好覆盖了DataHandler的三个要求,这个未分割职责的设计相对更上层的逻辑而言是单一职责的,但从下层影响它的因素看,三个方法都很可能会受到不同外部因素的影响,这样看它又不够单一职责.

例如:
1. 数据源是文件还是数据库
2. 格式化为二进制数据还是XML数据
3. 写入数据到数据库还是MQ.
可以说,三个方法都可能受到不同外部因素的影响,进而导致这个未分割角色的DataHandler发生变化.

实际项目中,我们要把握好单一职责中单一的度最好是一个原因引起一个类的变化,例如,在极端的情况下,项目中每个类的每个方法都独立定义为一个接口,这样彻底单一的结果就不完整了,因为这样 极端设计违背了面向对象的封装的要求.

单一职责原则的意义:
1. 降低类的复杂性,使类有清晰的定义,如实体类People只需要有属性及相应的set get方法而不应该有eat,sleep等业务逻辑方法.
2. 提高代码可读性.
3. 提高可维护性.
4. 降低变更引起的风险,拥抱变化.