ZAČÁTKYNÁVODYOOPDOKUMENTACE
PHP中的面向对象编程/
PHP中的OOP系列

PHP中的设计模式

13. 02. 2020

Obsah článku

设计模式是思考编程的方式。

它们提供了一个建议、现成的做法、最佳实践和对发展的见解的集合。对于每种编程范式和任务类型,都有某些设计模式是最适合的。

优点--为什么使用设计模式?

在编程中,解决某些类型的问题是重复性的,所以选择一种方法来解决这些问题并不断重复这种方法是有意义的。

特别是在团队开发过程中,当每个人都知道应用程序将如何开发(根据哪种设计模式)时,他们就会应用它,这就是主要的好处。这样就省去了不必要的几十个小时来调试写得很奇怪的代码,并试图理解作者的意图原则。

MVC--一个使用设计模式的例子

我最喜欢的设计模式是 "MVC"(来自 "模型-视图-控制器"),它说应用程序被分为3个独立的层,按顺序相互调用,并相互传递数据。

例如,当渲染一个页面时,它可能看起来像首先决定它是什么类型的页面(例如,一个类别的细节),所以它调用CategoryControllerdetail方法。

一个具体的例子(我简化了很多)。

class CategoryController
{
public CategoryManager $categoryManager;
public function actionDetail(string $id): void
{
$this->template->id = $id;
$this->template->category = $this->categoryManager->getById($id);
}
}

注意:

这只是一个解释MVC设计模式原理的示例代码。

在真正的实现中,我们必须进一步弄清楚,例如,如何获得CategoryManager的实例,以及如何将其传递给属性。通常情况下,"依赖注入 "被用于这种类型的任务。

在渲染类别细节的页面之前,首先调用CategoryController来接收实际的请求(即我们要渲染具有某个ID的类别细节,这个ID是由路由器获得的,例如在URL中),获得数据(查询相应的Model)并将最终数据传递给模板进行渲染。

这一原则的巨大优势在于,我们可以编写许多模型(应用逻辑),这些模型与数据的呈现方式(模板)无关,从而产生可重用的代码。事实上,如果我们想在另一个项目中使用CategoryManager,我们只需通过Controller以特定的方式传递数据,它将根据项目本身定义的模板进行渲染,而应用逻辑保持不变,没有人关心,因为软件层已经完成了它约定的接口和责任。

实践说明:

MVC设计模式被大多数现代框架所使用,如Nette、Symfony、Laravel和其他框架。

在移动应用开发和其他类型的软件中,我们也可以遇到MVC,我们需要获得数据并根据页面或视图类型在模板中呈现。

网页开发的重要设计模式

一般来说,在编程中,有许多设计模式并不适合于网络开发。这个列表描述了我自己使用的最重要的模式,你应该熟悉这些模式。

所有设计模式的完整列表、其使用实例和详细解释可在另一个页面上找到。

  • MVC - 将一个应用程序分为 "模型"(应用逻辑和数据)、"视图"(模板和数据视图)和 "控制器"(连接 "模型 "和 "视图")的原则。
  • 依赖性注入 - 我们不创建类实例,而是定义所谓的服务,并自动注入。代码承认所有的依赖性,个别部分可以被调换,我们动态地构建应用程序。
  • 单子(Singleton) - 每个类只有一个实例(我个人将此与 "依赖性注入 "结合使用,每个服务只有一个实例,在整个应用程序中传递)。
  • 懒惰的初始化(延迟初始化) - 我们在第一次需要时创建一个对象的实例。
  • Adapter - 如果我们需要在两个不兼容的类之间提供通信,Adapter将数据从一种类型转换为另一种类型(通常是将本地PHP数据类型转换为数据库数据类型,再转换回来)。
  • Command - 我们不直接执行一个特定的任务(例如,发送一封电子邮件),而只是记住它应该发生。然后,另一个或相同的进程将接过请求并进行处理。主要优点是我们可以懒散地处理应用程序(因此非常快),重试失败的动作,并简单地存储调用的参数。同时,这将使我们能够接收来自不同客户的请求,通过API等。已发送的行动也可以排队,优先处理,并可能在评估前取消。
  • 策略 - 封装了某种要改变的算法或对象,以便它们对客户来说是可以互换的。

还有很多设计模式,这些是你应该知道的最重要的。

反模式

一些编程开发技术被认为是 "反模式",这与设计模式完全相反。它通常是一种产生奇怪代码的技术,这些代码不容易调试、维护,并且表现得很 "神奇"。

一个典型的例子是使用global variables

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Související články

1.
4.