客户端SRP原则实践：类实例化与职责划分技术咨询

问题1：拆分后的Name、Address类，应嵌入Person类耦合，还是通过通用ID建立关联？ #

在客户端维护对象状态的场景下，优先选择将Name、Address作为成员变量嵌入Person类，而非通过通用ID建立关联。

• Name和Address是Person的固有属性，在客户端场景中通常没有脱离Person独立存在的业务价值。拆分这两个类的核心目的是让各自承担单一职责：比如Name负责姓名的格式化、合法性校验，Address负责地址解析、区域编码匹配等。
• 用ID关联会额外增加客户端状态维护的复杂度——需要单独维护ID映射关系的状态，还要处理关联对象的加载、同步问题，这完全没必要，反而违背了客户端状态轻量化维护的初衷。嵌入方式既能保证职责拆分，又能让Person类方便组合调用Name、Address的方法，状态一致性也更易维护。

问题2：Loan类的实例化位置，是否取决于其是否需持有与特定Person绑定的状态（如doesHaveALoan）？ #

是的，实例化位置完全由是否需要绑定特定Person的状态决定。

• 如果Loan需要持有和特定Person绑定的状态（比如该用户的贷款额度、还款状态、逾期记录等），应该由Person类持有Loan实例（可在Person内部实例化，也可外部创建后注入）。客户端维护状态时，这种绑定关系是Person状态的一部分，直接关联持有能保证状态一致性，也方便业务逻辑中直接访问Person的贷款相关状态。
• 如果Loan是通用工具类（比如仅提供贷款计算的静态方法），或者不需要绑定特定Person的状态，可在需要调用的地方直接实例化，无需和Person类耦合。

问题3：当类中单个属性对应多个独立方法，且该属性及方法与类内其他成员无协同关系时，是否需立即拆分新类？ #

优先拆分，除非是极端简单且无扩展预期的场景。

• 从SRP的核心逻辑来看，这个属性和对应的方法已经形成独立职责，和类内其他成员无协同，说明当前类承担了至少两个无关职责。在客户端维护状态时，拆分后每个类仅维护自身状态和逻辑，不仅更易理解，后续的状态更新、序列化、逻辑扩展都会更清晰，也能避免类随业务迭代变得臃肿。
• 只有当该属性的方法极其简单（比如仅两个基础格式化方法，且明确不会添加新逻辑），才可暂时不拆，但这是权宜之计，长远来看拆分更符合OOP设计原则。

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