PHP面向对象分析设计：61条核心军规与最佳实践

拾光

发布时间：2026-10-13 | 2人浏览过

原创

本文汇总了PHP面向对象分析的61条设计军规，深入探讨如何运用封装、继承和多态等核心概念优化代码结构。重点包括隐藏实现细节、控制类间耦合、合理规划继承体系以及避免过度设计，旨在为PHP开发者提供一套可落地的架构指导原则。

核心设计哲学：封装与关注点分离

面向对象设计的基石在于数据的保护与接口的简化。以下是关于类内部数据访问及外部交互的关键规则：

数据隐藏：所有数据都应隐藏在所在类的内部，严禁直接暴露给外部[1]。
依赖方向：类的使用者必须依赖类的公有接口，但类本身不能反向依赖其使用者，以确保松耦合[2]。
协议精简：尽量减少类公共接口中的消息（方法）数量，降低使用难度[3]。
基础接口统一：所有类都应理解并实现最基本的公有接口，如拷贝操作（深/浅拷贝）、相等性判断、内容输出及解析功能[4]。
拒绝暴露细节：切勿将实现细节（如提取共用代码的私有函数）放入公有接口中。若多个公有方法有公共代码，应封装为私有函数[5]。
避免干扰：不要在公有接口中放置用户无法使用或不感兴趣的功能，保持接口纯净[6]。
零耦合或导出耦合：类之间要么毫无关系，要么仅通过另一个类的公有接口进行操作，禁止内部耦合[7]。
单一抽象：每个类只表示一个关键抽象，确保职责明确[8]。
相关性与集中性：将与某类相关的数据和行为集中放置；反之，不相关的信息应移至其他类[9][10]。
依赖稳定化：设计时应朝着稳定的方向进行依赖，避免依赖频繁变化的模块[10]。
建模本质：为之建模的抽象概念必须是真正的“类”，而非仅仅是对象扮演的临时角色[11]。
水平分布：系统功能应在水平方向上统一分布，顶层类应平等地共享工作负载[12]。

类的设计陷阱与反模式规避

许多设计问题源于对类和组件边界的模糊处理。以下规则用于识别和消除不良设计：

警惕全能类：系统中不应创建“上帝类”或“全能对象”。对名为 Driver, Manager, System, Subsystem 的类需格外小心，它们往往违反了单一职责原则[13]。
规划接口：先规划接口再实现具体逻辑，有利于后期维护和扩展[13]。
检查访问器泛滥：若类定义了海量访问方法（Getters/Setters），说明数据和行为未集中存放，需重构[14]。
检查行为割裂：若类包含大量互不沟通的行为，表明该类的职责过多，应拆分[15]。
模型与界面分离：在与UI交互的应用中，模型不应依赖界面，但界面必须依赖模型，符合MVC模式的解耦要求[16]。
现实世界建模：尽量按照现实世界的逻辑进行建模，除非这严重违反了功能分布、全能类避免或数据集中的原则[17]。
去除冗余类：设计中不需要类时，不要保留。通常可将降级为该对象的属性，移除不必要的包装类[18]。
去除外部类：移除那些只发送消息但不接收系统内其他类消息的“系统外类”，它们通常是多余的抽象[19]。
操作非类：质疑名字是动词或派生自动词的类。如果类只有一个有意义的行为，考虑将该行为迁移至已存在或隐含的类中[20]。
清理代理：在分析阶段引入的代理类，在设计阶段若发现无用，应予剔除[21]。

耦合度与控制复杂性

降低复杂性的最有效手段是限制协作关系的广度和深度：

减少协作者数量：一个类使用的其他类数目应尽可能少[22]。
减少消息数量：类和协作者之间传递的消息总数应最小化[23]。
减少不同消息数：即减少协作的种类，避免琐碎的通信[24]。
限制扇出：类的扇出（定义消息数 × 发送消息数）应尽量小，以控制复杂度[25]。
包含即使用：若类A包含类B的对象，则A应当主动给B发送消息，确立拥有权和控制权[26]。
成员一致性：类中定义的大多数方法应使用大多数数据成员，避免“死数据”或“孤立方法”[27]。
记忆容量限制：类包含的对象数目建议不超过6个（短期记忆极限）。超过此数量应将逻辑相关的成员分组，新建包含类来聚合[28]。
垂直分布功能：系统功能应在窄而深的继承体系中垂直分布，而非横向堆砌[29]。

约束实现与状态管理

语义约束（Constraints）的正确处理方式直接影响系统的健壮性：

基于类定义实现约束：最好根据类定义来实现约束。若导致类泛滥，则应在类行为中实现，通常在构造函数中执行[30]。
深层约束测试：在构造函数中实现约束时，应将测试放在允许的尽量深的层次结构中，确保对象初始化的合法性[31]。
高频变动约束：若约束依赖的语义信息经常改变，应置于一个集中式的第三方对象中，便于统一管理[32]。
低频变动约束：若语义信息很少改变，可分布在各个涉及的类中[33]。
知晓边界：类必须知道它包含什么，但不能知道谁包含它，以保持独立性[34]。
同域对象解耦：共享同一父级包含范围（Scope）的对象之间不应有直接使用关系，避免紧耦合[35]。
非公开状态修改：严禁绕开公有接口去修改对象的状态，以保障数据完整性[61]。

继承体系的黄金法则

继承是强大的工具，但极易滥用。请严格遵循以下继承规范：

特化建模：继承只应用于构建特化（Specialization）层次结构[36]。
单向知晓：派生类必须知道基类，但基类不应知道任何关于派生类的信息[37]。
私有数据：基类中所有数据均应为私有，尽量避免使用 protected 数据，以防破坏封装[38]。
理论vs实践深度：理论上继承体系越深越好，实践中深度不应超过普通人的短期记忆能力（建议值为6）[39][40]。
抽象与基类等价：所有的抽象类都应当是基类，所有的基类都应当是抽象类，避免实例化基类造成混淆[41][42]。
共性上移：将数据、行为和接口的共性尽可能放到继承体系的高端[43]。
共享数据策略：
- 若多个类共享数据但无共同行为，创建一个包含数据的类供各共享类组合引用[44]。
- 若多个类共享数据和行为，则应从表示这些内容的公共基类继承[45]。
- 若多个类仅共享接口（消息），仅在需要多态使用时才从公共基类继承[46]。
拥抱多态：避免对对象类型进行显式的分情况分析（Switch/Case），应利用多态处理[47]。同样，避免对属性值进行显式分情况处理，而应将其转化为不同的派生类[48]。
静态而非动态：不要用继承关系为类的动态语义建模。试图用静态语义模拟动态语义会导致运行时类型切换，这是危险的[49]。
谨慎单例派生：不要把类的对象变成派生类。对只有一个实例的派生类要格外小心，通常它们是设计失误的信号[50]。
对象而非新类：若感觉需要在运行时创建新类，退后一步认清你要创建的是“对象”。将这些对象概括为一个现有的类即可[51]。
禁止空覆写：在派生类中用空方法覆盖基类方法应当是非法的，这违背了里氏替换原则[52]。
可选组合非继承：不要把“可选包含”建模为继承，否则会导致类爆炸[53]。
框架优于组件：创建可复用的框架，而不是简单的可复用组件[54]。
慎用多重继承：若使用了多重继承，先假设自己犯了错。若非错误，需设法证明其必要性[55]。
继承自问二题：每次使用继承时问自己：(1) 派生类是否是基类的一种特殊类型？(2) 基类是不是派生类的一部分？若答案不符，则不应使用继承[56]。
菱形继承禁忌：确保没有哪个基类实际上是另一个基类的派生类，避免复杂的菱形继承问题[57]。
优先组合关联：若在包含和关联间犹豫，请选择包含关系（Composition over Inheritance）[58]。
类变量记账：不要用全局数据或全局函数进行类的对象记账工作，应使用类变量或类方法[59]。
逻辑优先于物理：物理设计准则不应破坏逻辑设计，但在决策过程中可参考物理准则[60]。