和ChatGPT的首次合作：论单一职责原则

最新推荐文章于 2024-09-10 14:56:43 发布

于连林_

最新推荐文章于 2024-09-10 14:56:43 发布

阅读量84

点赞数

文章标签：单一职责原则

原文链接：https://mp.weixin.qq.com/s?__biz=MzI1MzI2NDI3Mw==&mid=2247485895&idx=1&sn=d90c42ff424dc1c62e47e08ea4c080a5&chksm=e9d66139dea1e82fa272278df9376c5b693b45a3d071ed06dcd23df56a57916606e3b0747f62&scene=126&sessionid=0

版权

▲ 点击上方“老于的笔记”关注公众号

回复1，免费获取B端运营地图

正文来了

今天刚在卫生间解决完个人问题出来，就听老婆说：回去开灯。顿时一阵懵，大白天的人家都是别忘关灯，怎么到你这里成了别忘开灯了。老婆又连说了两遍，我依然没有反应过来。直到老婆说：就是排风扇打开，我才恍然大悟。因为装修的时候出现失误，卫生间的排风开关不好用，排风开关和卫生间的灯弄成一个了，导致排风就得开灯，开灯就得排风。

这就是一个开关两个职能导致的混乱。这让我想起在架构设计的一些基本原则中一条非常重要的原则：单一职责原则（Single Responsibility Principle，SRP）。

👇跟技术讲产品，跟产品讲技术

架构中的单一职责原则

在软件系统架构设计中，单一职责原则是一个基础原则，它强调一个组件或模块只应该拥有一个单一的职责。这个原则可以使得架构设计更加清晰，使得组件之间的耦合更加清晰分离，从而带来更好的可维护性和可拓展性。

例如，我们可以将一个复杂的业务逻辑划分为多个模块或组件，每个模块或组件只负责一项职责。这样可以使得每个模块或组件更加专注和独立，避免出现复杂的交叉依赖关系，提高代码的可读性和可维护性。

单一职责原则是实现高内聚、低耦合的指导方针,在很多代码重构手法中都能找到它的存在,它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

产品中的单一职责原则

单一职责原则是软件开发中重要的设计原则之一，它提倡将一个类或模块的职责尽可能的单一化，从而使得类或模块只负责一种功能。单一职责原则在产品设计中也是存在的。

首先，单一职责原则可应用于产品功能设计中。 在产品设计中，每个产品都必须具有一定的功能，而单一职责原则在这个过程中起到了关键作用。通过将产品功能进行细分，将不同的功能委托给不同的模块，可以使得各个模块之间的功能职责清晰且互不干扰。以智能音箱为例，它需要完成听音乐，查询天气，设置闹钟等多种功能。如果将这些功能都放入一个模块中实现，不仅难以管理和维护，而且不同功能之间的干扰会严重影响用户体验。因此，一个好的产品设计应该将不同的功能划分为不同的模块来实现单一职责原则。

其次，单一职责原则可以应用于产品组件设计中。 在产品设计过程中，设计师往往需要设计各种不同的组件，并且需要保证各个组件之间的兼容性。如果每个组件都有多种功能，会使得组件之间的逻辑关系变得复杂，难以维护和修改。因此，设计师需要将不同的功能拆分为不同的组件，并且保证每个组件只具有一种功能，这样在后期的修改和维护中，就能够更加方便和快捷。

最后，单一职责原则可以应用于产品界面设计中。 一个好的界面设计应该呈现出清晰的布局和设计，让用户可以更加方便和快捷的使用产品。在设计过程中，应该将不同的功能组织在对应的区域中，并且保证每个区域只具有一种功能。这样不仅能够方便用户的使用，而且能够使得界面更加简洁和美观，极大提升用户体验。

单一职责原则在产品设计中的应用不仅会使得产品的各个模块之间的职责更加清晰，而且能够使得产品更加方便、易用、易维护。因此，在产品设计中的单一职责原则应用是非常必要且重要的。

管理中的单一职责原则

在组织管理中，单一职责原则可以帮助我们更好地进行任务分配和责任划分。每个人应该只承担自己熟悉和能够完成的任务，避免过度承担任务导致工作质量下降、效率低下等问题。

例如，在一个软件开发团队中，每个开发人员应该只负责特定模块或组件的开发，避免出现过度依赖一个人的情况，并且每个人都可以专注于自己的工作，提高整个团队的生产效率和代码质量。

另外，在职场组织管理中，单一职责原则也可以帮助我们更好地进行岗位设置和角色分配。每个岗位或角色应该只涉及自己的专业领域和职责范围内的工作，从而提高组织的工作效率和管理效果。

在管理中，管理者可能出现兼职的情况，或者一人身兼数职。比如研发总监的岗位人员空缺了，产品总监兼职研发总监，如果我们不能根据场景或者任务清晰的实现角色切换的时候，往往就出现了混乱，导致设计产品时过度的考虑研发的资源和进度。或者项目交付的过程中，随意的添加或者变更的产品的需求。所以，岗位兼职应该是一种短期行为用于过渡，长期来看，还是需要清晰划分职责，特别是有相互制衡的岗位一定要拆分为单一职责。

有一次在做技术评审时，针对大量设备对接的程序设计，对于设备对接适配器的调用，产品开发人员采用了根据写死的设备编码进行if-else的判断实现不同设备的调用。但是问题来了，实际到了项目实施以及运维过程中，还会有新的设备加进来，我们如果要不停的修改核心产品中的if-else代码，产品的稳定性就会变差，而且本来可以交由外部实施团队来做的开发又只能回到产品研发团队，这是不合理的。之所以出现这种设计，其实就是现阶段，产品开发人员同时兼职项目实施，当前所有适配的设备都是由他负责，所以没有做产品和项目的拆分，没有做扩展性的设计。这也是职责不单一导致的系统设计混乱！

当我提醒他，你做程序设计的时候，不要认为你就是最终做项目实施的人，你应该怎么做？你做项目实施的时候，你希望什么模式可以不通过修改产品就能解决？当我们职责无法实现单一的时候，我们应该从多维角色中跳出来，切换为单一职责去思考。