《班的职责为什么要简化？简化类的职责容易吗？首先要提醒看这篇文章的同学，我觉得一个类（一定要是类吗？）的单一职责保证不是一件容易的事。开闭原则软件实体应该是可扩展的，而不是可修改的。也就是说，它对扩展开放但对修改关闭。这个原理是众多面向对象编程原理中最抽象、最难理解的。Liskov替换原则所有对基类的引用必须能够透明地使用其子类的对象。换句话说，只要引用基类，就可以用子类替换子类。依赖倒置原则具体可以概括为两点：高层模块不应该直接依赖低层模块，而应该依赖抽象。抽象不应该依赖于具体的实现。具体实现应该依赖于抽象接口。换句话说，一个程序只依赖于它需要的接口。从纯概念的角度来看，单一职责原则可以说是最简单易懂的原则。和设计模式中的单例模式一样无聊，是这样吗？谁的职责老实说，我看了很多解释《单一职责》设计原则的文章，都是用类来描述的，其实我认为是错误的，单一职责设计原则本质上是一个软件设计原则的思想，具有指导意义。至于谁的职责需要单一，这是一个伪命题，不仅是指面向对象编程中的类，系统模块，甚至微服务中都应该遵循这个规则架构设计在面向对象设计的理解中，程序最基本的单位是类（class），多个类组成一个模块（module），多个模块组成一个服务（service），多个服务组成一个系统（系统），而一般软件系统中都会存在以上概念，无论是类、模块、服务还是系统，我认为在设计时一定要保证“单一职责”。单身容易吗？说到“单一”职责，大家看法不一classUserInfo{//useridpublicintUserId{get;get;set;}//用户名publicstringName{get;set;}}以上是最常见的用户信息实体，你觉得它职责单一吗？说说我自己的看法：从用户信息的角度来说，这个类代表用户信息，它是单一的，这是大多数人的想法，是不是错了？其实是的。因为在当前情况下，确实如此。随着业务的发展，用户的信息字段会越来越多，比如：用户的年龄、性别、教育背景……等。看着越来越大的UserInfo类，是不是应该拆分？这个时候我觉得你可以按照用户信息的类型来拆分。毕竟，大而全的班级不好。怎么拆分呢？例如：用户认证的类型可以根据用户登录场景进行拆分set;}}可以根据用户信息在系统中出现的频率和重要程度拆分用户基本信息和用户扩展信息手机号publicstringPhone{get;set;}//其他基本属性}classUserExtendnfo{//用户邮箱publicstringEmail{get;set;}//用户QQ号publicstringQQ{get;set;}//其他属性}当然，我在这里举个栗子。如果用户的Email和手机号一样常用，可以在基本属性中提及Email属性。以上只是举个栗子，以用户信息为例，根据不同的用途进行拆分。在不同的业务背景和不同的业务阶段，同一类的拆分可能会有很大的不同。有时候，你认为“正确”的东西，会随着系统的发展逐渐变得“错误”。当然，这种“错误”并不可怕，毕竟系统的架构是慢慢迭代的。总之，评价一个类是否必须满足单一原则，并没有统一的标准和规范。在实际开发中，没有必要过度设计。在项目的初始阶段，可以是满足业务需求的大而全的类，随着业务的发展，必然会经历拆分的过程，这也是软件开发的必然阶段。以上只是聊了下类最基本的面向对象单元。在模块和系统方面也是如此。微服务也随着软件开发的不断演进而出现。其实从职责来看，微服务也是职责单一原则的产物，而且这个单一更倾向于业务的单一性，而不是功能的单一性。职责分工是否越细越好？我不这么认为。当一个类或模块甚至一个系统拆分得太细时，就会面临维护问题。以微服务为例，当微服务数量过多时，会面临治理等一系列问题，这也是K8s要解决的问题之一。归根结底，拆分原则，虽然由于职责单一，主观上很难做出准确的判断，但还是有一些通用的规则可以借鉴的。这里我们以类作为高内聚的例子。系统修改任何功能时，只需要修改一个地方。如果你需要修改多个地方来满足某个需求，很可能是你的职责分工不合理，属性太多。当一个类的属性过多时，可以考虑拆分这个类的职责。至于多少太多了？当找某个属性让你很头疼的时候，说明已经到了可以拆分的地步（自己编的）依赖太多了。当一个类型依赖太多资源时，可以独立拆分和更改。当一个类的某些属性被广泛使用并且经常变化时，可以考虑将这些属性拆分到单独的类中。说到单一职责，顺便提一下接口的设计。接口的设计应遵循单一职责的原则。接口本质上是业务的抽象。不同的业务要抽象成不同的接口，保证每个类、每个模块、每个系统都可以独立扩展。写在最后没有绝对好的办法让大家觉得你的拆分是正确的“单一职责”。有时候，如何做到单一职责，真的要靠“灵感”。《教师修行之路》，可通过以下二维码关注。转载本文，请联系建筑师修行路径公众号。
