一种非 OO 的 PHP 设计模式，PHP 模式最适合这种情况答案

【问题标题】：A PHP design pattern that is not OO, PHP pattern best suited to this situation一种非 OO 的 PHP 设计模式，PHP 模式最适合这种情况
【发布时间】：2010-11-15 06:54:05
【问题描述】：

我们得到了一个 php 库存程序。然后我们应该说设计模式是否会使程序变得更好，或者它是否只会使程序更复杂。

程序的结构是这样的。

该程序被分解为嵌入 html 的 php 脚本。要么有 (A) 一个完整的 php 页面专用于一个选项，要么 (B) 一个选项的逻辑位于另一个脚本页面内，该页面服务于类似操作的其他选项。（这不包括“重置”和“返回主页”等简单按钮。）

(A) 例如，一旦您打开网站，就会出现一个带有选项的导航菜单。当您单击一个选项时，例如在客户下，有一个“查看”链接。单击后，您将被带到另一个页面，其中包含与更多选项相对应的其他链接，例如“编辑”和“删除”。通常，对于这个网站，每个选项都对应着自己的 php 脚本页面。例如，“查看”对应于 list_customers.php。 “编辑”对应于edit_customer.php。

(B) 可能发生的另一件事是该选项的逻辑位于“通用”脚本页面中。我的意思是几个选项的逻辑被分组到一个页面中。这方面的一个例子是“删除”。在删除客户、工作订单或报价之前，需要将其定向到名为 auth.php 的 php 脚本页面，以确保只有管理员可以删除。检查是否是管理员登录以及删除客户、工作订单或报价单的逻辑也在 auth.php 中。另一个例子是客户的所有“搜索”选项。虽然它有自己的页面search_customer.php，但实际搜索的逻辑实际上在list_customers.php 中。此模式适用于所有搜索，包括搜索客户、报价或交付报告；搜索代码其实在对应的list_*.php页面中。

我发现很难找到一种不会使其变得更复杂的设计模式。我发现的大多数都是面向 OO 范式的，而这个清单当然不是。工厂模式当然无济于事，因为我发现它的唯一有用方法是登录（用户名和密码）更改为（用户名、密码、ID 号）之类的东西。但是，我认为这不会有用，因为只有 2 个 php 页面具有登录功能。

我还想看看是否所有的搜索逻辑都可以组成一个对象。但是，每种类型的搜索都必须有自己的方法（因为它们正在查询 diff.tables），这与当前设置不会有太大不同（每个搜索当前都在相应的列表 php 页面中。）

我发现可能唯一有用的是正则表达式的设计模式。程序中的表格未经验证。你有什么想法吗？

此外，课程的主题是软件质量。我个人的看法是设计模式会使这个网站变得更复杂，因为它不是一个大项目。但是我的同学争辩说，由于它不是面向对象的，所以它不是可维护的。但我在想，PHP 不是 OO，我说的对吗？所以强迫它符合 OO 设计模式只会把事情搞砸。

你怎么看？任何可能适用于这种情况的设计模式？

【问题讨论】：

您发现的大多数模式都涉及 OOP，因为那是模式概念首次应用于编程的地方。
非常感谢大家。习惯了Java，我可以说OO肯定更易于维护。特别感谢戈登。事务脚本正是我想要的！再次感谢您抽出宝贵时间。

标签： php oop design-patterns procedural-programming

【解决方案1】：

然后我们应该说设计模式是否会使程序更好，或者它是否只会使程序更复杂。

设计模式是常见问题的常见解决方案。你不使用设计模式来使用设计模式。您使用它们来解决特定问题。最突出的设计模式来自GOF 和POEAA。其中一些很容易实现，例如策略，而另一些则需要更多的架构思想。

您甚至不知道就使用了一些设计模式，例如，您的动作脚本对我来说听起来像TransactionScript。是的，您可以将它们变成PageController 以减少脚本中的样板代码。然后，您可以添加 FrontController 以减少 PageControllers 中的样板。既然如此，为什么不使用 MVC 将业务逻辑和 UI 分开呢？

一般来说，设计模式将使您的代码从长远来看更易于维护，特别是如果您保持您的实现GRASP、SOLID 和DRY。设计模式还将使您的代码更易于理解和讨论，因为模式是定义明确的术语。告诉开发人员这段代码是工厂代码，他/她会理解你。

但是，是的，设计模式也可能使您的代码更加复杂，您应该知道在哪里停止以防止过度设计。这并不是说不要使用它们，而是在可以解决特定问题的地方合理使用它们。也可以考虑了解一下常见的AntiPatterns。

由于课程是关于软件质量的，您应该知道软件质量不是以代码中设计模式的数量来衡量的。软件质量是通过许多指标来衡量的，并且有一些工具可以衡量它们。看看Quality Assurance in PHP Projects 了解一下。

顺便说一句，设计模式不一定必须与 OOP 一起使用。 OOP 只是一种组织代码的好方法，许多设计模式确实针对但不限于 OOP。 MVC 可以与过程代码一起使用。您可以将 Strategy 和 Factory 与匿名函数一起使用，FrontController 可以是一个简单的 switch/case 语句，等等。这是因为设计模式是架构蓝图，而且大多与语言和范式无关。

【讨论】：

【解决方案2】：

OO 是一种很好的方式。它确实使代码更易于维护。它确实是编程的未来，而 php 是面向 OO 的绝佳语言。

【讨论】：

【解决方案3】：

PHP 5+ 相当 OO。并且您应该尝试以 OO 的方式做任何事情，即使它是一个单页脚本。这里的基本原理是，这一页很有可能会增长或将用于其他内容。

并且不要在没有很好理解的情况下尝试应用设计模式，当然也不要为了称其为模式而混入一个模式。请参阅Design Patterns 上的这个 SO 问题。

【讨论】：