领导说我的类的职责不单一

个原则说的详细一点其实可以概括为两点：

高层模块不应该直接依赖于底层模块，应该依赖于抽象

抽象不应该依赖于具体实现，具体实现应该依赖于抽象

接口隔离原则

程序不依赖于不使用的接口，换句话说，一个程序只依赖于它需要的接口。

单纯从概念上讲呢，单一职责原则可算是最简单易懂的一种原则了，就像设计模式中的单例模式一样无趣，是这样吗?

谁的职责

说实话，看过不少讲解“职责单一”设计原则的文章，都是以类来阐述。其实我觉得不对，职责单一设计原则本质上是软件设计原则的一种思想，具有指导意义。至于谁的职责需要单一，是一个伪命题，不仅仅指面向对象编程中的类，系统的模块，甚至于微服务在架构设计中也应该遵循此规则。

在面向对象设计的理解中，程序最基本的组成单位是类(class)，多个类组成模块(module)，多个模块组成服务(service)，多个服务组成系统(system)，一般的软件系统都会存在以上几个概念。

无论是类，还是模块，还是服务，还是系统，我认为设计的时候都要保证“单一职责”。

单一真的容易吗

说到“单一”职责，每个人都有不同的看法

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!