我们得到了一个php清单程序。然后我们应该说一个设计模式是会使程序更好,还是只会使程序更复杂。
程序的结构是这样的。
程序被分解成嵌入了html的php脚本。要么有(a)一个完整的php页面专用于一个选项,要么(b)一个选项的逻辑在另一个脚本页面中,该脚本页面为类似操作的其他选项提供服务。(这不包括简单的按钮,如“reset”和“back to home”。)
(a)例如,打开网站后,会出现一个带有选项的导航菜单。当你点击一个选项,比如在customer下,有一个“view”链接。单击后,您将转到另一个页面,其中包含与更多选项相对应的其他链接,如“编辑”和“删除”。通常,对于这个网站,每个选项都对应于自己的php脚本页面。例如,“view”对应于list_customers.php。“edit”对应于edit_customer.php。
(b)可能发生的另一件事是,该选项的逻辑在“通用”脚本页中。我的意思是多个选项的逻辑被组合成一个页面。一个例子是“delete”,在删除客户、工作订单或报价单之前,需要先指向一个名为auth.php的php脚本页面,以确保只有管理员可以删除。检查是否是管理员登录和删除客户、工单或报价单的逻辑也在auth.php中。另一个例子是针对客户的所有“搜索”选项。尽管它有自己的页面search_customer.php,但实际搜索的逻辑实际上在list_customers.php中。此模式适用于所有搜索,包括搜索客户、报价或交货报告;搜索代码实际上位于相应的list.*.php页面中。
我发现很难找到一个设计模式,不会使它更复杂。我发现的大多数都是面向对象的范例,而这个清单当然不是。工厂模式肯定不会有帮助,因为我找到它的唯一有用的方法是如果登录(用户名和密码)更改为类似(用户名、密码、ID号)。但是,我认为这不会有用,因为只有两个php页面具有登录功能。
我还想看看是否所有的搜索逻辑都可以变成一个单独的对象。但是,每种类型的搜索都必须有自己的方法(因为它们正在查询diff.tables),这与当前的设置没有太大区别(每个搜索当前都在相应的list php页面中)。
我发现唯一有用的是正则表达式的设计模式。程序中的表单未验证。你有什么想法吗?
此外,课程的主题是软件质量。我个人的意见是,一个设计模式将使这个网站更复杂,因为它不是一个大项目。但我的同学认为,既然不是oo,就没有那么容易维护。但我在想,PHP不是OO,我说的对吗?因此,强迫它遵循oo设计模式只会把事情搞砸。
你怎么认为?是否有适用于这种情况的设计模式?
最佳答案
然后我们应该说一个设计模式是会使程序更好,还是只会使程序更复杂。
设计模式是常见问题的常见解决方案。你不能用设计模式来使用设计模式。你用它们来解决一个特定的问题。最突出的设计模式是来自GOF和POEAA的模式。它们中的一些很容易实现,比如策略,而另一些则需要更多的架构思想。
有些设计模式你甚至不知道,例如,你的动作脚本听起来像TransactionScript。是的,您可以将它们变成PageController来减少脚本中的样板代码。然后可以添加FrontController来减少pagecontrollers中的样板文件。既然如此,为什么不将业务逻辑和ui与mvc分开呢?
一般来说,设计模式将使代码在长期内更易于维护,特别是在保持实现GRASP、SOLID和DRY的情况下。设计模式还将使您的代码更易于理解和讨论,因为模式是定义良好的术语。告诉开发人员这段代码是工厂代码,他/她会理解你的。
但是是的,设计模式也可能使代码更加复杂,您应该知道在哪里停止,以防止过度工程化。这并不是说,不要使用它们,而是合理地使用它们来解决特定的问题。还可以考虑学习commonAntiPatterns。
因为类是关于软件质量的,所以您应该知道,软件质量不是通过代码中设计模式的数量来衡量的。软件质量是用许多度量来衡量的,并且有工具来衡量它们。看看Quality Assurance in PHP Projects就知道了。
另一方面,设计模式不一定要与oop一起使用。oop只是组织代码的一种很好的方式,许多设计模式确实是面向对象的,但不限于oop。MVC可以与过程代码一起使用。可以使用带有匿名函数的策略和工厂,前端控制器可以是简单的开关/ case语句,等等。这是因为设计模式是架构蓝图,主要是语言和范例不可知的。