orderservice实现类报编译错误是因为违反接口隔离原则（isp），被迫实现未使用的方法；应按角色拆分为orderqueryable、ordercreatable等小接口，避免臃肿和空实现。
为什么 OrderService 实现类要报编译错误？
当你让一个类实现一个包含 create()、delete()、queryById()、notifyExternal()、exportToExcel() 的大接口时，哪怕它只用其中两个方法，也必须实现全部——否则编译失败。这不是语言限制，而是接口设计违背了 ISP：客户端（即这个类）被强迫依赖了它完全不用的接口。
- 常见错误现象：
Class 'UserOrderQuery' must implement inherited abstract member 'delete()' from class 'OrderService' - 根本原因：把“谁调用”和“调用什么”混在一起设计，没按角色切分能力边界
- 正确做法：拆出
OrderQueryable（只含queryById()、listByUser()）、OrderCreatable（只含create()、validate()）等小接口 - 注意：C++ 中不能用
interface关键字，但可用纯虚类模拟；Java/Kotlin/Go 接口天然支持这种拆分
怎么判断一个接口是不是“臃肿”？看调用方是否总在写空实现
如果三个模块使用同一个接口，但各自只调用其中 1–2 个方法，且至少有一个模块反复写 throw new UnsupportedOperationException("not supported") 或 return null;，那这个接口已经违反 ISP。
- 典型场景：电商系统中，
OrderManager（后台）、ThirdPartyClient（外部系统）、UserApp（前端 App）都依赖同一个OrderApi接口 - 参数差异：后台需要
updateStatus(String id, OrderStatus status)，外部系统只要pushOrder(Order order)，App 只要getRecentOrders(int limit)—— 它们根本不需要彼此的方法 - 性能影响：大接口导致 IDE 自动补全变慢、文档难以聚焦、mock 测试成本上升（你得 mock 所有方法，哪怕只测一个）
C++ 里怎么安全拆接口？别直接继承多个抽象基类
C++ 没有接口关键字，靠纯虚类模拟，但多重继承容易引发菱形继承或 ambiguous 错误。稳妥做法是让实现类分别持有各小接口的指针，用组合代替继承。
class OrderQueryable { public: virtual Order queryById(const std::string& id) = 0; };
class OrderCreatable { public: virtual bool create(const Order& o) = 0; };
class UserOrderService {
private:
std::unique_ptr<OrderQueryable> query_;
std::unique_ptr<OrderCreatable> create_;
public:
explicit UserOrderService(std::unique_ptr<OrderQueryable> q,
std::unique_ptr<OrderCreatable> c)
: query_(std::move(q)), create_(std::move(c)) {}
};
- 避免踩坑：不要让
UserOrderService同时继承OrderQueryable和OrderCreatable—— 除非你明确控制虚继承与覆盖逻辑 - 兼容性：这种方式在 C++11+ 完全可行，且比模板特化更易测试和替换依赖
- 关键点：接口粒度由调用方决定，不是由“功能看起来相关”决定。比如
notifyExternal()和exportToExcel()虽都算“后续动作”，但触发方、协议、失败重试策略完全不同，不该塞进同一接口
拆得太细会怎样？当心“接口雪崩”
把每个方法都单独拎成接口，比如 OrderByIdQueryable、OrderByTimeQueryable、OrderCountQueryable，会导致调用方要注入一堆对象，反而增加耦合和理解成本。
- 信号提示：一个类构造函数参数超过 4 个接口类型，或单元测试里要 mock 6+ 个不同接口实例
- 适度原则：按“角色 + 场景”聚合，比如
AdminOrderOperable（增删改查+导出）是合理的，但OrderExportable单独存在就过细，除非导出逻辑跨服务复用且完全独立 - 容易被忽略的地方：接口命名必须反映真实职责，而不是技术动作。
OrderNotifier比OrderSendable更准确，因为“通知”隐含了渠道、重试、幂等性等契约，而“发送”只是动词
