用途：把面向对象设计原则当作系统架构的思考工具，用于代码组织、模块边界与组件关系的判断。核心前提是：面向对象设计不是关于类和继承，而是通过稳定接口把决策局部化，从而控制变更成本——需求变化时，需要改动的文件越少越好。
主要能力：
- SOLID 作为诊断框架。单一职责关注“变更原因”是否一致，而非类的大小；开闭原则用于已有第三个变体时提取扩展点，避免过早抽象；里氏替换要求子类型遵守行为契约，可用“能否删掉类型检查”检验；接口隔离按角色拆分接口，可用测试中的 mock 数量检验；依赖倒置让高层与低层都依赖抽象，但需避免 DI 配置过度。
- 组合优于继承。继承会带来脆弱基类问题，并把子类耦合到父类实现；委托、混入与 trait 是替代路径。仅当存在真实且契约稳定的 is-a 行为关系、模板方法模式或框架明确设计的继承扩展点时才用继承。
- Actor 模型。每个 actor 拥有私有状态，仅通过异步消息通信，一次处理一条消息，从而消除共享可变状态。关键模式包括邮箱、监督树、位置透明与行为切换。适合并发、有状态、需故障隔离的单元；无状态请求处理、紧耦合计算或简单发布订阅则属过度设计。
- 设计模式。模式是命名过的诊断工具而非菜谱。工厂在出现第二、第三个实现时才有价值；建造者在缺少命名参数的语言中更有用；单例易引入全局状态与测试困难，可改为创建单实例并传递。
使用方式与限制：资料未提供具体安装命令、调用接口或代码示例，仅给出原则性指导。各原则均有失效模式，需结合实际痛点判断，避免预防性套用导致过度抽象。