声明：本文非博主原创，来自《Laravel 4 From Apprentice to Artisan》阅读的翻译理解，当然不是原译，可以保证90分%原创，另外由于是理解翻译，难免有错误，欢迎指正。欢迎转载，转载请注明出处，谢谢！开放封闭原则介绍在项目的整个生命周期中，绝大部分时间都花在维护现有代码上，而不是整天写新功能。你会意识到这是一个艰巨的过程。对代码的任何修改都会带来破坏原始设计和引入新错误的风险。理想情况下，我们应该像编写新代码一样快速简单地修改旧逻辑。如果在设计中能够正确运用开闭原则，就可以很好地避免这些问题。开放封闭原则SOLID设计原则中的开放封闭原则是指代码对扩展开放，对修改关闭。真正的探索下面继续探索上一章基于OrderProcessor的开闭原理。对于处理方法中的逻辑：$recent=$this->orders->getRecentOrderCount($order->account);if($recent>0){thrownewException('Duplicateorderlikely.');}这段代码非常容易阅读，并且使用依赖注入使其易于测试。但是，如果调整验证的业务规则呢？如果添加新规则怎么办？事实上，随着业务的发展，必然会有_很多_新规则！处理方法很快就会变得臃肿且难以维护。因为从开放封闭原则来看，他是开放修改的，所以只要需求一变，我们就得改代码。请记住，我们希望对扩展而不是修改持开放态度。我们没有在流程中直接使用订单验证，而是定义了一个新的接口OrderValidator：OrderRepository$orders){$this->orders=$orders;}publicfunctionvalidate(Order$order){$recent=$this->orders->getRecentOrderCount($order->account);if($recent>0){thrownewException('可能有重复订单。');}}}伟大的！至此一个小的可度量的单一业务规则封装类就完成了。让我们创建一个检测用户是否被暂停的接口实现：order.")}}}现在我们已经有了OrderValidatorInterface接口的两个实现类，我们来看看如何在OrderValidatorInterface中使用它们。我们只需要在订单处理类实例化的时候注入验证类，这样我们就可以很方便的在原有订单处理代码的基础上增加或者删除验证规则。类OrderProcessor{publicfunction__construct(BillerInterface$biller,OrderRepository$orders,array$validators=array()){$this->biller=$biller;$this->orders=$orders;$this->validators=$validators;}}接下来，您只需要在process方法中访问验证：publicfunctionprocess(Order$order){foreach($this->validatorsas$validator){$validator->validate($order);}//处理有效订单...}最后，我们需要将OrderProcessor绑定到应用程序IoC容器：App::bind('OrderProcessor',function(){returnnewOrderProcessor(App::make('BillerInterface'),App::make('OrderRepository'),array(App::make('RecentOrderValidator'),App::make('SuspendedAccountValidator'),),);});这些更改只会产生最小的影响，我们现在可以在不更改原始代码的情况下添加或删除新的验证规则。每个新的验证规则只是OrderValidatorInterface的一个实现，并被注入到容器中。不需要对原来庞大臃肿的流程方法进行单元测试，现在只需要单独测试新的验证规则。现在代码对扩展_open_对_modification_关闭。Jade有缺陷要注意依赖的实现细节。当依赖项中的实现细节发生变化时，用户逻辑不应随之改变。当发生这种情况时，我们认为依赖关系中的实现细节是“有漏洞的”。当抽象逻辑出现漏洞时，开闭原则也会被打破。在继续之前，要知道开闭原则并不是一成不变的。并非代码中的所有地方都必须支持“热插拔”。比如简单的小规模获取几行MySQL数据库数据的逻辑，并不需要你严格按照那些设计原则去写代码。不要为了使用而将这些设计原则强加到编码中，这会使你的系统过度设计并变得臃肿。许多设计原则是为解决大型复杂系统而提出的通用解决方案。但是不要用这些话作为偷懒的借口。
