基于Interface Segregation Principle的多客户端共享库接口命名最佳实践问询

核心原则：以职责为命名核心，而非绑定客户端 #

ISP的本质是让接口对应单一、明确的职责，而非服务于特定客户端，这是解决你困惑的根本方向。

• 共享接口：优先按职责命名
  不管是App1还是App2使用的接口，不要用IApp1这类客户端绑定的名称，而是提炼接口提供的核心能力。比如接口负责处理支付请求，就命名为IPaymentHandler；负责读取配置，就叫IConfigurationReader。这样只要客户端需要对应职责，就可以直接依赖，完全不会出现命名混淆的问题，也避免了重复创建接口。

• 专属接口：先找通用职责，再考虑客户端标识
  对于App3这类使用独特方法集的场景，先不要直接命名为IApp3。先拆解它的职责：如果这个接口的方法是App3独有的业务逻辑（比如仅App3需要的设备状态同步），可以在职责命名基础上加上客户端标识，比如IApp3DeviceStatusSync；但如果能拆出通用职责，优先拆分——比如App3的接口里有SyncStatus()和LogDeviceEvent()，可以拆成通用的IDeviceStatusSync和IDeviceEventLogger，App3同时依赖这两个小接口，既符合ISP，又保留了复用性。

• 避免代码重复：用接口继承拆分职责
  如果不同客户端的接口有重叠方法，不要直接复制代码。比如App1需要ValidateOrder()和ProcessOrder()，App2需要ProcessOrder()和NotifyCustomer()，可以先定义基础接口IOrderProcessor（仅包含ProcessOrder()），然后让IApp1OrderService继承IOrderProcessor并添加ValidateOrder()，IApp2OrderService继承IOrderProcessor并添加NotifyCustomer()。这样既满足各客户端的专属需求，又避免了代码重复，命名也清晰易懂。

• 临时名称的过渡建议
  目前用临时名称测试是可行的，但要尽早完成职责梳理和命名重构。可以先列出每个接口的所有方法，提炼出核心职责，再对应到精准的命名上，避免后期维护时出现命名混乱的问题。

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