【面向对象设计原则】之单一职责原则(SRP)

单一职责原则是面向对象原则五大原则中最简单，也是最重要的一个原则， 他的字面定义以下：

单一职责原则(Single Responsibility Principle, SRP): 一个类只负责一个功能领域中的相应职责，或者能够定义为：就一个类而言，应该只有一个引发它变化的缘由。

从定义中能够看出在定义类的时候要将职责划分清楚， 不能让一个类负责干多个事情。换句话说就是一个类只有一个引发他变化的点。若是一个类负责干多个事情那么就会有多个引发他变化的缘由。那么这个类就不稳定了，这个类就容易变化，由于咱们知道若是干的事情越少变化的诱因就愈少，若是干的事情越多变化的诱因就愈多。变化的越多引发bug的可能性就越大， 最终就会影响到你设计的系统容易出现bug，反之系统出现bug的肯能性就越小。

如今咱们有这么一个场景，对人员信息的维护， 一般对用数据库的操做以下：

    public class Employee
    {
        public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }
        public DateTime BirthDay { get; set; }
    }

    public class EmployeeRepository
    {
        public void Create(Employee employee)
        {
            DataBase<Employee> dataBase = new DataBase<Employee>();

            dataBase.Create(employee);
        }

        public IEnumerable<Employee> Query()
        {
            DataBase<Employee> dataBase = new DataBase<Employee>();

            return dataBase.Query();
        }
    }

咋一看这个设计彷佛是没有问题的，可是在看看咱们刚刚讲的那个原则，其实这个设计已经违背了我么的SRP原则，主要是EmployeeRepository 类的职责太多，它包含的两个方法，一个是给数据库中建立数据一个是查询数据，从这个拆分粒度上来讲是EmployeeRepository 承担了两个职责。 所以咱们因该将他拆分开来以下：

public class EmployeeRepository
    {
        public void Create(Employee employee)
        {
            DataBase<Employee> dataBase = new DataBase<Employee>();

            dataBase.Create(employee);
        }
    }

    public class EmployeeQuery
    {
        public IEnumerable<Employee> Query()
        {
            DataBase<Employee> dataBase = new DataBase<Employee>();

            return dataBase.Query();
        }
    }

这样咱们就将原来的EmployeeRepository中的查询数据的职责拆分到EmployeeQuery类中,这样EmployeeRepository就只负责对数据的"写"操做而EmployeeQuery 只负责对数据"读"操做, 这就回到了计算机的本质上来了, 即计算机的本质就是 "读写".

写到这里就应该告一段落了, 可是我想不少人都会说第一个EmployeeRepository 的职责划分的也能够啊,只负责数据的操做啊, 其实这个问题也没有错, SRP原则自己就是一个充满争议的原则, 每一个人对类的组织不一样,职责的划分不一样, 系统的规模不一样对SRP使用也是不一样, 对SRP的把握粒度也不一样,这要根据具体问题具体对待.