我们得到了一个 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_*中。
我发现很难找到一种不会使它变得更复杂的设计模式。我发现的大多数都是面向 OO 范式的，而这个清单当然不是。工厂模式当然无济于事，因为我发现它的唯一有用方法是登录（用户名和密码）更改为（用户名、密码、ID 号）之类的东西。但是，我认为这不会有用，因为只有 2 个 php 页面具有登录功能。
我还想看看是否所有的搜索逻辑都可以做成一个对象。但是，每种类型的搜索都必须有自己的方法（因为它们正在查询 diff.tables），这与当前设置不会有太大不同（每个搜索当前都在相应的列表 php 页面中。）
我发现唯一可能有用的是正则表达式的设计模式。程序中的表格未经验证。你有什么想法吗？
此外，该课程的主题是软件质量。我个人的看法是，设计模式会使这个网站变得更复杂，因为它不是一个大项目。但是我的同学争辩说，由于它不是面向对象的，所以它不是可维护的。但我在想，PHP 不是 OO，我说的对吗？因此，强迫它符合 OO 设计模式只会把事情搞砸。
你怎么看？任何可能适用于这种情况的设计模式？