如何优化PHP项目的代码复用？

本文目录导读：

1. 遵循SOLID原则（面向对象基础）
2. 利用设计模式（常见复用模式）
3. 架构分层与依赖注入（架构级复用）
4. 工具与代码组织（工程化复用）
5. 实际编码技巧（日常复用手册）
6. 框架原生功能利用（以 Laravel 为例）
7. 注意反模式（避免复用的陷阱）
8. 总结建议

优化PHP项目的代码复用是提升开发效率、降低维护成本的核心手段，下面从设计模式、架构分层、工具链和实际技巧四个维度，为你梳理一套系统的优化策略：

遵循SOLID原则（面向对象基础）

这是代码可复用的基石,尤其关注“开闭原则”和“里氏替换原则”。

• 单一职责： 一个类或函数只做一件事，不要写一个既负责数据库查询又负责生成HTML的类。
• 依赖倒置： 依赖抽象（接口），而非具体实现，这样更换数据库（MySQL→PostgreSQL）时，上层代码无需改动。

利用设计模式（常见复用模式）

PHP 的 OOP 特性非常适合实现经典设计模式：

1. 策略模式： 解决同类算法（如支付、快递、通知）的替换问题。PaymentProcessor 接受 PaymentStrategy 接口，具体实现 AlipayStrategy 或 WechatStrategy 可自由切换。
2. 工厂模式： 创建复杂对象时避免到处 new。LoggerFactory::create('file') 或 LoggerFactory::create('database')。
3. 观察者模式： 事件驱动，适合解耦（如用户注册后发邮件、加积分），Laravel 的 Event / Listener 就是此模式的实现。
4. 模板方法模式： 定义算法骨架，子类重写特定步骤，报表生成：父类定义 生成表格 -> 填充数据 -> 导出PDF/CSV，子类实现 填充数据 的具体逻辑。

架构分层与依赖注入（架构级复用）

采用 MVC 或更现代的架构

• 控制器（Controller）：薄（只负责接收请求、调用服务、返回响应）。
• 服务层（Service Layer）：存放核心业务逻辑（如 OrderService::createOrder()），这是复用的核心战场，控制器、API、CLI 命令、队列任务均可调用。
• 仓库层（Repository）：封装数据访问，切换数据源（ORM vs 原生SQL）时只改这一层。
• 模型（Model）：只定义属性、关系，不写业务逻辑。

依赖注入容器

使用依赖注入容器（PHP-DI、Laravel Service Container、Symfony DI）管理对象依赖，好处是：

• 代码不依赖具体类,而是依赖接口。
• 单元测试时可轻松注入模拟对象（Mock）。

工具与代码组织（工程化复用）

1. Composer 私有包： 将通用模块（如短信发送、日志、权限校验）提取为独立包，用 composer require 引入，跨项目复用最有效。
2. Traits（小心使用）： 当类需要共享方法但不适用继承时，可用 trait，但避免过度使用，防止代码逻辑隐式耦合。
3. 创建辅助函数类： 把重复的“小工具”（如时间格式化、数组排序、加密算法）封装到 Utils 类或独立命名空间中，与业务逻辑隔离。
4. 服务容器统一注册： 将第三方库（如 Guzzle、Monolog）通过服务容器配置，而非直接 new，这样更换实现只需改一处配置。

实际编码技巧（日常复用手册）

• 参数化查询：将查询条件作为参数传递，而非硬编码。
• 抽象重复流程：所有数据库操作前的“事务开始-执行-提交或回滚”流程，可用一个公共函数/方法封装。
• 使用中间件/管道模式：对请求进行统一的预处理或后处理（如日志记录、权限检查、参数验证），Laravel、Slim 等框架均支持。
• 避免复制粘贴： 当你发现自己第三次复制同一段代码时，就该抽象了。

框架原生功能利用（以 Laravel 为例）

现在的 PHP 框架已内置大量复用支持：

注意反模式（避免复用的陷阱）

• 上帝类：一个类包含太多不相关的功能，强行复用会导致难以维护。
• 过度抽象：不要为只出现一次的代码创建复杂模式，YAGNI（你不会需要它）原则很重要。
• 陷阱：继承过深：超过 3 层继承，维护成本急剧上升，尽可能用组合代替继承。

总结建议

1. 从现实需求出发：先找项目中出现 3 次以上的代码片段。
2. 优先用 Composer 管理：如果是通用功能（加密、发送邮件、支付），优先搜索 Packagist 上成熟的包，而非自己实现。
3. 先 Service 化，再 Package 化：先在项目内通过服务层实现复用，等稳定后提取为独立包。
4. 配合版本控制：复用代码一定要有接口文档和单元测试，否则会变成“黑盒”难以调试。

最终目标是：业务代码只写一次，变更时只改一处，不同地方共享同一份逻辑。 这样你的项目会在长期迭代中越来越“轻盈”。