我们获得了一个php库存程序。然后我们应该说一个设计模式是否会使程序更好，或者它是否只会使程序更复杂。
该程序的结构如下。
该程序分为嵌入html的php脚本。要么（A）一个完整的php页面专用于一个选项，要么（B）选项的逻辑位于另一个脚本页面内，该脚本页面用于类似操作的其他选项。 （这不包括诸如“重置”和“返回主页”之类的简单按钮。）
（A）例如，一旦您打开网站，就会出现一个带有选项的导航菜单。当您单击某个选项时，例如在“客户”下，会出现“查看”链接。单击后，您将进入另一个页面，其中包含与更多选项对应的其他链接，例如“编辑”和“删除”。通常，对于本网站，每个选项对应于其自己的php脚本页面。例如，“View”对应于list_customers.php。 “编辑”对应于edit_customer.php。
（B）可能发生的另一件事是该选项的逻辑位于“通用”脚本页面中。我的意思是将几个选项的逻辑分组到一个页面中。一个例子是“删除”。在删除客户，工作订单或报价之前，可以将一个指向名为auth.php的php脚本页面，以确保只有管理员可以删除。检查是否管理员登录和删除客户，工作单或报价单的逻辑也在auth.php中。另一个例子是Customer的所有“搜索”选项。尽管它有自己的页面search_customer.php，但实际搜索的逻辑实际上是在list_customers.php中。所有搜索都遵循此模式，包括搜索客户，报价或交付报告;搜索代码实际上在相应的列表_ * .php页面中。
我发现很难找到一种不会让它变得更复杂的设计模式。我发现的大多数都适用于OO范例，而这个库存当然不是。工厂模式肯定无济于事，因为我找到的唯一有用的方法是登录（用户名和密码）更改为（用户名，密码，ID号）。但是，我认为这没有用，因为只有2个php页面具有登录功能。
我还查看是否可以将所有搜索逻辑组成单个对象。但是，每种类型的搜索都必须拥有它自己的方法（因为它们正在查询差异表），并且与当前设置不同（每个搜索当前都在相应的列表php页面中。）
我发现可能唯一有用的是正则表达式的设计模式。程序中的表单未经过验证。你有什么想法吗？
此外，该课程的主题是软件质量。我个人认为，设计模式会使这个网站变得更加复杂，因为它不是一个大项目。但是我的同学们争辩说，因为它不是OO，所以它不具备可维护性。但我在想，PHP不是OO，我是对的吗？因此，强制它符合OO设计模式只会搞砸了。
你怎么看？任何可能适用于这种情况的设计模式？答案 0 :(得分：4)
然后我们应该说一个设计模式是否会使程序更好，或者它是否只会使程序变得更复杂。
设计模式是常见问题的常见解决方案。您不使用设计模式来使用设计模式。您可以使用它们来解决特定问题。最突出的设计模式来自GOF和POEAA。其中一些很容易实现，比如Strategies，而另一些则需要更多的架构思想。
您使用的某些设计模式甚至不知道，例如，您的操作脚本听起来像TransactionScript。是的，你可以将它们变成PageController以减少脚本中的样板代码。然后，您可以添加FrontController以减少PageControllers中的样板。当你在那时，为什么不将业务逻辑和UI与MVC分离？
通常，设计模式可以使您的代码在长期内更易于维护，特别是如果您保留实施GRASP，SOLID和DRY。设计模式还将使您的代码更易于理解和讨论，因为模式是明确定义的术语。告诉开发人员这段代码是工厂，他/她会理解你。
但是，设计模式也可能使您的代码更加复杂，您应该知道在哪里停止以防止过度工程。不要说，不要使用它们，但要合理地使用它们来解决特定问题。还要考虑了解常见的AntiPatterns。
由于该课程属于软件质量，因此您应该知道软件质量不是以代码中的设计模式数量来衡量的。软件质量以多种指标衡量，并且有测量它们的工具。看看Quality Assurance in PHP Projects以获得一个想法。
在旁注中，设计模式不一定必须与OOP一起使用。 OOP只是组织代码的一种很好的方式，很多设计模式确实是针对的，但不限于OOP。 MVC可以与过程代码一起使用。您可以使用策略和工厂与匿名函数，FrontController可以是一个简单的开关/案例语句，等等。这是因为设计模式是架构蓝图，主要是语言和范例不可知。
答案 1 :(得分：0)
答案 2 :(得分：0)
PHP 5+非常OO。并且您应该尝试以OO方式执行大多数操作，即使它是单页脚本。这里的基本原理是这个页面很可能会增长或将用于其他内容。
并且不要在不理解它的情况下尝试应用设计模式，当然不要仅仅将模式称为模式。请参阅Design Patterns上的这个问题。