不是OO的PHP设计模式，最适合这种情况的PHP模式

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

程序的结构是这样的

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

（A） 例如，打开网站后，将显示一个带有选项的导航菜单。当你点击一个选项时，比如在Customer下，有一个“查看”链接。单击后，您将进入另一个页面，该页面包含与更多选项相对应的其他链接，如“编辑”和“删除”。通常，对于这个网站，每个选项都对应于它自己的php脚本页面。例如，“视图”对应于list_customers.php。“Edit”对应于Edit_customer.php

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

我发现很难找到一个不会使它变得更复杂的设计模式。我发现的大多数是面向对象的范例，而这个清单肯定不是。工厂模式当然不会有帮助，因为我找到它的唯一有用方法是登录（用户名和密码）更改为类似（用户名、密码、id号）。但是，我认为这不会有用，因为只有2个php页面具有登录功能

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

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

此外，本课程的主题是软件质量。我个人的观点是，设计模式会使这个网站更加复杂，因为它不是一个大项目。但我的同学认为，因为它不是面向对象的，所以它就不那么容易维护。但我在想，PHP是作为非面向对象的，对吗？因此，强迫它符合OO设计模式只会把事情搞砸

---

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

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

PHP5+是非常面向对象的。你应该试着用面向对象的方式做任何事情，即使是一页脚本。这里的基本原理是，这一页很有可能会增长或被用于其他内容

不要试图在没有充分理解的情况下应用一个设计模式，当然也不要仅仅为了称之为模式而混入一个模式。看到这个问题了吗

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

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

你使用的一些设计模式甚至不知道，例如，你的动作脚本听起来像我。是的，您可以将它们制作成一个模板，以减少脚本中的样板代码。然后，您可以在PageController中添加一个简化样板文件。既然如此，为什么不使用MVC分离业务逻辑和UI呢

一般来说，从长远来看，设计模式将使代码更易于维护，特别是如果您保留了实现，并且。设计模式还将使您的代码更易于理解和讨论，因为模式是定义良好的术语。告诉开发人员这段代码是出厂代码，他/她会理解您的

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

因为这个课程是关于软件质量的，所以您应该知道，软件质量不是用代码中设计模式的数量来衡量的。软件质量是用许多度量标准来衡量的，有很多工具来衡量它们。看一看就知道了

另一方面，设计模式不一定要与OOP一起使用。OOP只是组织代码的一种很好的方式，许多设计模式确实是针对OOP的，但不限于OOP。MVC可以与过程代码一起使用。您可以将Strategy和Factory与匿名函数、FrontControlle一起使用