在 Laravel 中，哪些组件是刻意避免使用某些模式的？

Laravel 的设计哲学并非“无脑堆砌”设计模式，而是有意识地选择、融合甚至刻意规避某些模式，以避免过度工程、性能损耗或开发体验下降。

---

1.避免深度继承（Deep Inheritance） → 拒绝模板方法模式的滥用

❌ 被规避的模式：模板方法模式（Template Method） via Deep Class Hierarchy

✅ Laravel 的替代方案：组合 + 接口 + Trait

• 现象：
  在早期 PHP 框架（如 CodeIgniter）或 Java 体系中，控制器、模型常通过继承基类实现功能（如class UserController extends BaseController），基类再继承更上层抽象，形成深继承树。

• Laravel 的态度：

  • 控制器默认只继承App\Http\Controllers\Controller（它本身几乎为空，仅use AuthorizesRequests, DispatchesJobs, ValidatesRequests;）。
  • 功能通过Trait（如AuthorizesRequests）注入，而非父类方法。
  • 核心服务（如 Request、Response）通过接口（Illuminate\Http\Request实现Arrayable,Jsonable等）和依赖注入耦合，而非继承。

• 为什么避免：

  • 继承导致紧耦合和类爆炸；
  • 难以测试（父类副作用难以隔离）；
  • 违背你强调的“组合优于继承”原则。

💡 Laravel 用Trait 提供横切关注点，用接口定义契约，用容器管理依赖——这比模板方法更灵活、更可测。

---

2.避免单例模式（Singleton）作为全局访问点

❌ 被规避的模式：传统单例（通过 static getInstance()）

✅ Laravel 的替代方案：容器管理的单例绑定（Singleton Binding）

• 现象：
  传统单例模式通过MyClass::getInstance()提供全局唯一实例，常导致：

  • 难以 Mock（静态方法）；
  • 隐藏依赖（调用处不显式声明依赖）；
  • 测试污染（状态跨用例残留）。

• Laravel 的态度：

  • 不鼓励用户写static单例类；
  • 但允许通过 Service Container 注册单例绑定：

    $this->app->singleton(MyService::class,function($app){returnnewMyService(...);});

  • 获取时通过依赖注入或app(MyService::class)，而非静态方法。

• 为什么避免传统单例：

  • 保持显式依赖（构造函数注入）；
  • 支持测试时替换实现（容器可重绑定）；
  • 与你强调的“避免全局状态”一致。

✅ Laravel 的“单例”是生命周期管理策略，而非访问控制模式。

---

3.避免“纯”观察者模式（显式订阅/发布 API）

❌ 被规避的模式：显式 Observer 注册（如e v e n t − > a t t a c h ( event->attach(event−>attach(listener)）

✅ Laravel 的替代方案：事件/监听器自动发现 + 队列化 + 广播

• 现象：
  经典观察者模式要求手动注册监听器，容易遗漏或耦合。

• Laravel 的态度：

  • 通过EventServiceProvider声明事件-监听器映射；
  • 支持自动发现（Laravel 8+）；
  • 监听器可轻松队列化（ShouldQueue）、条件触发（shouldHandle()）；
  • 但不暴露底层订阅机制（如没有$event->on(...)API）。

• 为什么避免显式观察者 API：

  • 降低使用门槛；
  • 统一事件处理生命周期；
  • 避免运行时动态注册导致的不可预测性（不利于缓存与调试）。

🔍 Laravel 的事件系统是观察者模式的“声明式封装”，而非“命令式暴露”。

---

4.避免“纯”工厂模式（显式 Factory Class）

❌ 被规避的模式：独立的UserFactory、ConnectionFactory类（GoF 风格）

✅ Laravel 的替代方案：Service Container + 自动解析 + 延迟绑定

• 现象：
  GoF 工厂模式通常需要定义专门的工厂类。

• Laravel 的态度：

  • 容器本身就是超级工厂，通过make()、build()自动解析依赖；
  • 对于复杂创建逻辑，使用Closure 绑定或服务提供者（Service Provider）；
  • 例如数据库连接由DatabaseManager（一个工厂）管理，但用户从不直接调用它——而是通过DB::connection()（Facade 代理）。

• 为什么避免独立工厂类：

  • 减少样板代码；
  • 利用容器统一管理生命周期；
  • 与你认同的“用容器解耦创建逻辑”一致。

---

5.避免“纯”装饰器模式（显式 Wrapper Class）

❌ 被规避的模式：手写CachedUserService extends UserService

✅ Laravel 的替代方案：Pipeline（管道） + Middleware + Macroable

• Laravel 如何替代：

  • HTTP 请求处理：通过Middleware 管道逐层装饰（如认证、日志、CORS）；
  • 任务处理：通过Job Middleware；
  • 对象行为扩展：通过Macroabletrait动态添加方法，而非继承或包装。

• 为什么避免传统装饰器：

  • 避免类爆炸（每个装饰组合需新类）；
  • 动态组合优于静态继承；
  • 更符合 PHP 动态语言特性。

---

总结：Laravel 的“模式选择性”

被规避的模式	Laravel 的替代方案	核心动机
深度继承 / 模板方法	Trait + 接口 + 组合	解耦、灵活、可测（组合 > 继承）
传统单例（静态）	容器单例绑定 + 依赖注入	显式依赖、可测试、无全局状态
显式观察者注册	声明式事件服务提供者 + 自动发现	简化使用、统一管理
独立工厂类	Service Container 作为统一工厂	减少样板、统一生命周期
显式装饰器类	Pipeline + Middleware + Macroable	动态组合、避免类爆炸

---

最后：Laravel 的设计哲学

Laravel 并非“不用模式”，而是：

只在必要时使用模式，并用更符合 PHP 特性与开发者体验的方式封装它，同时主动规避那些在现代 Web 开发中已显笨重或易被滥用的模式。

这与你一贯主张的“模式服务于问题，而非问题迁就模式”完全一致——实用性、可维护性、可测试性才是终极目标，而非对 GoF 的教条遵循。