是否存在与单一职责原则“相反”的职责集中原则？

这类原则的核心是高内聚，还有几个具体的设计原则完全契合你描述的“将特定任务/实体相关的所有职责集中到一处”的思路：

• 高内聚（High Cohesion）
  这是和单一职责原则互补的核心设计概念。单一职责强调拆分不同领域的职责到独立模块，而高内聚要求把同一业务实体、同一业务目标下的所有操作集中到同一模块，让模块内的逻辑紧密关联，服务于同一个核心目的。
  比如你提到的EntityService例子：把该Entity的CRUD、映射逻辑都放在EntityService里，就是高内聚的典型实践——所有和这个Entity相关的逻辑都集中在一起，避免分散到多个无关模块，后续维护时不用跨多个文件找相关代码。

• 信息专家原则（Information Expert Principle）
  这是GRASP设计原则中的一条，核心逻辑是：拥有完成某操作所需全部信息的类，应该负责执行该操作。
  比如Entity对应的服务类最清楚这个Entity的数据结构和业务规则，把Entity的映射逻辑放在这里，比放到全局通用映射器更合理——它不需要依赖外部模块获取信息，也能让数据和相关逻辑绑定在一起，降低耦合。

• 共同闭包原则（Common Closure Principle）
  这条原则属于敏捷软件开发原则，要求把会因为同一原因修改的代码放在一起。
  比如如果修改Entity的字段结构时，其业务逻辑和映射逻辑都需要同步调整，把这两部分放在同一个服务类里，就能避免在多个地方修改，减少出错概率，提升维护效率——这也是把相关职责集中的体现。

你提到的示例1（把对象运行所需的所有配置都放入构造函数，初始化后直接可用），本质也是高内聚的实践：把对象的初始化逻辑集中在一处，避免分散的初始化步骤，保证对象状态的完整性和一致性。

需要明确的是，这些原则和单一职责原则并不是完全对立的，而是互补的。单一职责是避免一个模块承担无关的职责，高内聚等原则是避免相关职责被过度拆分，两者的最终目标都是提升代码的可维护性和可读性，只是侧重点不同。

内容的提问来源于stack exchange，提问作者yaapelsinko