分类 laravel 下的文章

原文地址：装饰模式 (Decorator Pattern)

装饰模式能够实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。通常有两种方式可以实现给一个类或对象增加行为：

  • 继承机制，使用继承机制是给现有类添加功能的一种有效途径，通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法。但是这种方法是静态的，用户不能控制增加行为的方式和时机。
  • 组合机制，即将一个类的对象嵌入另一个对象中，由另一个对象来决定是否调用嵌入对象的行为以便扩展自己的行为，我们称这个嵌入的对象为装饰器(Decorator)

显然，为了扩展对象功能频繁修改父类或者派生子类这种方式并不可取。在面向对象的设计中，我们应该尽量使用对象组合，而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段，组合才是目的。总之，装饰模式是通过把复杂的功能简单化，分散化，然后在运行期间，根据需要来动态组合的这样一个模式。

- 阅读剩余部分 -

原文地址：观察者模式

Laravel的Event事件系统提供了一个简单的观察者模式实现，能够订阅和监听应用中发生的各种事件，在PHP的标准库(SPL)里甚至提供了三个接口SplSubject, SplObserver, SplObjectStorage来让开发者更容易地实现观察者模式，不过我还是想脱离SPL提供的接口和特定编程语言来说一下如何通过面向对象程序设计来实现观察者模式，示例是PHP代码不过用其他面向对象语言实现起来也是一样的。

模式定义

观察者模式(Observer Pattern)：定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。

观察者模式的核心在于Subject和Observer接口，Subject(主题目标)包含一个给定的状态，观察者“订阅”这个主题，将主题的当前状态通知观察者，每次给定状态改变时所有观察者都会得到通知。

发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间没有相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。

- 阅读剩余部分 -

原文链接：Facades

什么是Facades

Facades是我们在Laravel应用开发中使用频率很高的一个组件，叫组件不太合适，其实它们是一组静态类接口或者说代理，让开发者能简单的访问绑定到服务容器里的各种服务。Laravel文档中对Facades的解释如下：

Facades 为应用程序的 服务容器 中可用的类提供了一个「静态」接口。Laravel 本身附带许多的 facades，甚至你可能在不知情的状况下已经在使用他们！Laravel 「facades」作为在服务容器内基类的「静态代理」，拥有简洁、易表达的语法优点，同时维持着比传统静态方法更高的可测试性和灵活性。

我们经常用的Route就是一个Facade, 它是\Illuminate\Support\Facades\Route类的别名，这个Facade类代理的是注册到服务容器里的router服务，所以通过Route类我们就能够方便地使用router服务中提供的各种服务，而其中涉及到的服务解析完全是隐式地由Laravel完成的，这在一定程度上让应用程序代码变的简洁了不少。下面我们会大概看一下Facades从被注册进Laravel框架到被应用程序使用这中间的流程。Facades是和ServiceProvider紧密配合的所以如果你了解了中间的这些流程对开发自定义Laravel组件会很有帮助。

- 阅读剩余部分 -

原文地址：中间件

中间件(Middleware)在Laravel中起着过滤进入应用的HTTP请求对象(Request)和完善离开应用的HTTP响应对象(Reponse)的作用, 而且可以通过应用多个中间件来层层过滤请求、逐步完善响应。这样就做到了程序的解耦，如果没有中间件那么我们必须在控制器中来完成这些步骤，这无疑会造成控制器的臃肿。

举一个简单的例子，在一个电商平台上用户既可以是一个普通用户在平台上购物也可以在开店后是一个卖家用户，这两种用户的用户体系往往都是一套，那么在只有卖家用户才能访问的控制器里我们只需要应用两个中间件来完成卖家用户的身份认证：

class MerchantController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');
        $this->middleware('mechatnt_auth');
    }
}

在auth中间件里做了通用的用户认证，成功后HTTP Request会走到merchant_auth中间件里进行商家用户信息的认证，两个中间件都通过后HTTP Request就能进入到要去的控制器方法中了。利用中间件，我们就能把这些认证代码抽离到对应的中间件中了，而且可以根据需求自由组合多个中间件来对HTTP Request进行过滤。

再比如Laravel自动给所有路由应用的VerifyCsrfToken中间件，在HTTP Requst进入应用走过VerifyCsrfToken中间件时会验证Token防止跨站请求伪造，在Http Response 离开应用前会给响应添加合适的Cookie。（laravel5.5开始CSRF中间件只自动应用到web路由上）

上面例子中过滤请求的叫前置中间件，完善响应的叫做后置中间件。用一张图可以标示整个流程：
中间件.jpg

- 阅读剩余部分 -

来源：服务容器(IocContainer)

Laravel的核心是IocContainer, 文档中称其为“服务容器”，服务容器是一个用于管理类依赖和执行依赖注入的强大工具，Laravel中的功能模块比如 Route、Eloquent ORM、Request、Response等等等等，实际上都是与核心无关的类模块提供的，这些类从注册到实例化，最终被我们所使用，其实都是 laravel 的服务容器负责的。

如果对服务容器是什么没有清晰概念的话推荐一篇博文来了解一下服务容器的来龙去脉：laravel神奇的服务容器

服务容器中有两个概念控制反转(IOC)和依赖注入(DI):

依赖注入和控制反转是对同一件事情的不同描述，它们描述的角度不同。依赖注入是从应用程序的角度在描述，应用程序依赖容器创建并注入它所需要的外部资源。而控制反转是从容器的角度在描述，容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。

在Laravel中框架把自带的各种服务绑定到服务容器，我们也可以绑定自定义服务到容器。当应用程序需要使用某一个服务时，服务容器会讲服务解析出来同时自动解决服务之间的依赖然后交给应用程序使用。

- 阅读剩余部分 -

  1. 1
  2. 2