摘要:它是良好应用设计的大原则,包含单一责任原则开放封闭原则里氏替换原则接口分离原则依赖倒置原则让我们通过代码示例来深究下这五个原则。实探单一责任原则代表一个类有且仅有一个改变的原因,换言之,一个类的职责范畴是严谨明确的。
声明:本文并非博主原创,而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解,当然也不是原汁原味的翻译,能保证90%的原汁性,另外因为是理解翻译,肯定会有错误的地方,欢迎指正。
欢迎转载,转载请注明出处,谢谢!
单一责任原则 介绍“SOLID”设计原则,是Robert “Uncle Bob” Martin提出的理论。它是良好应用设计的5大原则,包含:
单一责任原则
开放封闭原则
里氏替换原则
接口分离原则
依赖倒置原则
让我们通过代码示例来深究下这五个原则。这5个原则相互****,一荣俱荣,一毁俱毁。
实探单一责任原则代表一个类有且仅有一个改变的原因,换言之,一个类的职责范畴是严谨明确的。我们之前说过对来说无知是福。类只需要干好自己的工作,对于其依赖变化的影响是无需感知的。
看下面这个类:
class OrderProcessor { public function __construct(BillerInterface $biller) { $this->biller = $biller; } public function process(Order $order) { $recent = $this->getRecentOrderCount($order); if ($recent > 0) { throw new Exception("Duplicate order likely."); } $this->biller->bill($order->account->id, $order->amount); DB::table("orders")->insert(array( "account" => $order->account->id, "amount" => $order->amount; "created_at" => Carbon::now(); )); } protected function getRecentOrderCount(Order $order) { $timestamp = Carbon::now()->subMinutes(5); return DB::table("orders") ->where("account", $order->account->id) ->where("created_at", ">=", $timestamps) ->count(); } }
该类的职责是什么?通过名字可以明确他就是来处理订单的。但是,从getRecentOrderCount方法中又能看到该方法需要对数据库中的历史订单进行检测以判断是否重复订单。额外的验证意味着在数据存储改变的情况下,我们的订单处理程序必须要进行验证规则的修改。
我们可以把这个职责提取到多带带的类OrderRepository中:
class OrderRepository { public function getRecentOrderCount(Account $account) { $timestamp = Carbon::now()->subMinutes(5); return DB::table("orders") ->where("account", $account->id) ->where("created_at", ">=", $timestamp) ->count(); } public function logOrder(Order $order) { DB::table("orders")->insert(array( "account" => $order->account->id, "amount" => $order->amount; "created_at" => Carbon::now(); )); } }
然后在OrderProcessor中注入类库,来减少它检测账户历史订单的职责:
class OrderProcessor { public function __construct(BillerInterface $biller, OrderRepository $orders) { $this->biller = $biller; $this->orders = $orders; } public function process(Order $order) { $recent = $this->orders->getRecentOrderCount($order->account); if ($recent > 0) { throw new Exception("Duplicate order likely."); } $this->biller->bill($order->account->id, $order->amount); $this->orders->logOrder($order); } }
现在我们将订单数据收集责任抽象出来,当获取记录订单的方法改变时,就无需再对OrderProcessor类进行修改了。现在的类库职责明确单一,代码简洁,表现力强,同时可维护性也大大的提升。
牢记,单一责任原则不是指代码越少越好,他是指写类是类的职责要非常明确,要有一套可用的方法,这些方法在类中要组成类的整体职责。根据既定的职责撰写出的这些巧而简洁的类,我们的代码就能是一个解耦的,可测的,可友好改变的架构。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/23006.html
摘要:实际上,本原则要求接口必须是粒度明确的。当你的代码不符合接口分离原则时,那也肯定违背了单一责任原则。接口分离原则本原则是指在实现类中对于接口中的方法并不强制去实现使用不到的方法。 声明:本文并非博主原创,而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解,当然也不是原汁原味的翻译,能保证90%的原汁性,另外因为是理解翻译,肯定会有错误...
摘要:可以为服务提供者的方法设置类型提示。方法将在所有其他服务提供者均已注册之后调用。所有服务提供者都在配置文件中注册。可以选择推迟服务提供者的注册,直到真正需要注册绑定时,这样可以提供应用程序的性能。 本文最早发布于 Rootrl的Blog 导言 Laravel是一款先进的现代化框架,里面有一些概念非常重要。在上手Laravel之前,我认为先弄懂这些概念是很有必要的。你甚至需要重温下PHP...
摘要:然而,我们需要注意的是仅是软件设计模式依赖注入的一种便利的实现形式。容器本身不是依赖注入的必要条件,在框架他只是让其变得更加简便。首先,让我们探索下为什么依赖注入是有益的。继续深入让我们通过另一个示例来加深对依赖注入的理解。 声明:本文并非博主原创,而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解,当然也不是原汁原味的翻译,能保证9...
摘要:编写组件时要考虑的基本准则是单一职责原则。这些更改通常要求组件在隔离状态下易于修改这也是的目标。解决多重责任问题需要将分割为两个组件和。组件之间的通信是通过实现。更改的唯一原因是修改表单字段。 翻译:刘小夕原文链接:https://dmitripavlutin.com/7-... 原文的篇幅非常长,不过内容太过于吸引我,还是忍不住要翻译出来。此篇文章对编写可重用和可维护的React组...
摘要:本文翻译改编自的十八个最佳实践这篇文章并不是什么由改编的原则模式等。只是为了让你注意你在现实生活的项目中最常忽略的内容。单一职责原则正在帮助你避免重复。当然,这也包括了模板的范围等。此外,也拥有很棒的内置工具,比如软删除事件范围等。 showImg(https://segmentfault.com/img/remote/1460000015166532); 本文翻译改编自 Larave...
阅读 2754·2023-04-25 22:51
阅读 1933·2021-10-11 10:58
阅读 3270·2019-08-30 10:49
阅读 1791·2019-08-29 17:09
阅读 3096·2019-08-29 10:55
阅读 790·2019-08-26 10:34
阅读 3389·2019-08-23 17:54
阅读 952·2019-08-23 16:06