应该有且有一个原因引起类的变更。
2.单一职责原则的好处 好处如下:类的复杂性降低，实现什么职责都有明确清晰的定义;
可读性提高，复杂性降低,那当然可读性提高;
可维护性提高，可读性提高，那当然更容易维护了;
变更引起的风险降低，变更是不必可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助;
注意:
单一职责原则提出了一个编写程序的标准，用”职责”或”变化原因”来衡量接口或类设计得是否优良，但是”职责”和”变化原因”都是不可度量得，因项目而异，因黄金而异。
对于单一职责原则，以我实际开发为例，在公司开发项目，基本上沿用得开发模式就是MVC,模型-视图-控制器，每个职责不一样。然后再往大的范围来说，分层，比如数据访问层、业务逻辑层、视图表现层(其中该层就是MVC的应用)。
数据访问层，通常编写的就是一些基础的CRUD，而业务逻辑层就是数据访问层里的CRUD一同用于处理某项业务。
还有就是单一职责的一个体现就是一个函数办一件事情，比方说业务逻辑层中修改密码(设计db操作修改用户信息)，最好是修改密码是一个方法，修改用户基本信息(例如昵称、性别、职位、籍贯等)是另外一个方法。不同的方法(不同的函数)办的事情不一样，我觉得这样也是单一职责的一个最好实践。记得刚工作第一年的时候，写代码基本上数据访问层就和业务逻辑层是一样的，这样的写法导致的后果是，如果是少量的五到六个类还好，但如果数十个的话或成百上千个这样写的话，后果将会非常严重，直接会导致维护成本的上升，可扩展性差、可维护性差等。
最后归纳一点，单一职责如果是以自己平时写写Demo玩玩而言实现起来并不困难。但是对于公司而言就不一样了，拿我曾经接手的一个项目来说，该项目采用jfinal框架，然后前任架构师对其又再度修改封装了很多东西，可以称之为扩展。当我接手这个项目的时候，初看项目结构，捋了下，大致能根据包名看出功能分层，但当我深入阅读的时候，发现太多的拼接sql，而且业务逻辑层和数据访问层并未分层明确，就像我们一般开发喜欢分为视图、业务、数据这样的分层，而这个项目基本上就是视图(一种是返回jsp，另外一种作为路由返回JSON数据)，业务实现(基本上就是写业务逻辑的)，还有较多的dto、request、response等包名下的众多类。
通常我所认为的最佳实践就是:
1.分层(表现层-业务逻辑层-数据访问层，每层做的事情不一样);
2.一个函数只办一件事情(也许你会发现你可能会编写比较多的函数，例如用户修改密码，一般可以修改用户信息就能实现，但是一般建议分为两个，因为这样一来当数据表结构发生变化，例如新增或修改字段，会降低很多影响，所以不要为了偷懒就用一个函数办两件或多件事情);
对于单一职责原则，接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
二、里氏替换原则继承的优点:
代码共享，减少创建类的工作量,每个子类都拥有父类的方法和属性;
提高代码的重用性;
子类可以形似父类，但又异于父类，例如”龙生龙，风生风，老鼠生来会打洞”，说的就是子拥有父的”种”;
“子”是指明子与父的不同;
提高代码的可扩展性，实现父类的方法就可以”为所欲为”了，君不见很多开源框架的扩张接口都是通过继承父类来完成的;
提高产品或项目的开放性;
继承的缺点:
继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法;
降低代码的灵活性。子类必须要拥有父类的属性和方法，让子类自由的世界中多了些约束;
增强耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕结果-一大段的代码需要重构;
1.里氏替换原则定义那么什么是里氏替换原则呢？
所有引用基类的地方必须能透明地使用其子类的对象。
通俗的来说:只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必适应。
2.规范里氏替换原则为良好的继承定义了一个规范，一句简单的定义包含4层含义。
(1)子类必须完全实现父类的方法