面向对象的设计原则之单一职责原则

1  定义

     单一职责原则（SRP，SingleResonsibility  Principle）：一个类应当只有一个改变它的原因。(There should never be more than one reason for aclass to change)

     换而言之就像人不能一心二用一样，一个类应该只做一件事和仅有一个使它改变的原因。如果一个类包含一个以上的职责的话，那么多个职责就会耦合一起，影响复用。例如在使用java web开发时n层架构模式就是单一职责的宏观体现，我们会把展示层、控制器、业务逻辑层、以及DAO层实现分离，每一层次的处理相互隔离，降低了耦合度，试想下我们如果将页面显示，业务逻辑处理，数据库的操作都写在页面上，将会出现什么样的后果？

2 单一职责原则举例

      单一职责原则从其定义非常好理解，虽然简单，却是非常重要的面向对象设计原则（当然单一职责原则并非面向对象设计独有）。回想一下我们曾经开发经历，虽然都知道应该设计类时应该职责分离，但是在开发的过程中，一时偷懒或者未经思考在一个类中临时加入一些不是此类职责的方法，积累变多时，发现系统应用变得杂乱不堪，业务逻辑也变得混乱，这时候维护也变得非常棘手，你是不是有过这样的经历呢？

     下面看个例子：当我们设计一个购物系统时，会设计用户类（User）和订单类（Order）,如果我们的用户类是如下设计的话：

public class User {
    public void addUser(){
       System.out.println("新增用户");
    }
    public void deleteUser(){
       System.out.println("新增用户");
    }
    public void upateUser(){
       System.out.println("更新用户");
    }
    public void queryUser(){
       System.out.println("查询用户");
    }
    public void queryOrder(){
       System.out.println("查询订单");
    }
}

        是不是看着都感觉别扭，用户类里出现订单的查询订单显得不伦不类，很明显用户类里出现了第二个改变它行为的原因即查询订单，违反了单一职责原则。因此我们需要对用户进行职责分离分成用户类（User）和订单类（Order类）。

User类：

public class User {
   public void addUser(){
       System.out.println("新增用户");
    }
    public void deleteUser(){
       System.out.println("新增用户");
    }
    public void upateUser(){
       System.out.println("更新用户");
    }
    public void queryUser(){
       System.out.println("查询用户");
    }
}

Order订单类:

public class Order {
    public void queryOrder(){
       System.out.println("查询订单");
    }
}

      这样User类和Order类的职责就会变得清晰不会耦合在一块了。这样系统设计的就会更健壮。

3 单一职责原则的优点

      单一职责原则分离对象间的职责，降低了对象间的依赖关系，那么也就降低了耦合度。有利于对象的稳定。

      它使得职责分离，代码更清晰，更易阅读。

       降低耦合度自然也增加的类和对象的复用性，增强系统的可维护性。

4 使用单一职责原则需要注意的地方

     使用单一职责原则有一个问题，“职责”没有一个明确的划分标准，如果把职责划分的太细的话会导致接口和实现类的数量剧增，反而提高了复杂度，降低了代码的可维护性。所以使用这个职责的时候还要具体情况具体分析。建议就是接口一定要采用单一职责原则，实现类的设计上尽可能做到单一职责原则，最好是一个原因引起一个类的变化。（引用别人的分析）