一种非OO的PHP设计模式，PHP模式最适合这种情况
我们得到了一个 php 库存程序。然后我们应该说设计模式是否会使程序变得更好，或者是否只会使程序变得更复杂。
该程序的结构如下。
该程序被分解为嵌入 html 的 php 脚本。要么 (A) 一个完整的 php 页面专用于一个选项，要么 (B) 选项的逻辑位于另一个脚本页面内，该脚本页面为类似操作的其他选项提供服务。 （这不包括“重置”和“返回主页”等简单按钮。）
(A) 例如，一旦您打开网站，就会出现一个带有选项的导航菜单。当您单击某个选项时，例如在“客户”下方，会有一个“查看”链接。单击后，您将进入另一个页面，其中包含与更多选项相对应的其他链接，例如“编辑”和“删除”。通常，对于该网站，每个选项都对应其自己的 php 脚本页面。例如，“View”对应于list_customers.php。 “编辑”对应于edit_customer.php。
(B) 另一件可能发生的事情是该选项的逻辑位于“通用”脚本页面中。我的意思是，几个选项的逻辑被分组到一页中。 “删除”就是一个例子。在删除客户、工作订单或报价单之前，用户会被引导至名为 auth.php 的 PHP 脚本页面，以确保只有管理员才能删除。检查是否是管理员登录以及删除客户、工作订单或报价单的逻辑也在 auth.php 中。另一个例子是客户的所有“搜索”选项。虽然它有自己的页面search_customer.php，但实际搜索的逻辑实际上在list_customers.php中。所有搜索都遵循此模式，包括搜索客户、报价或交付报告；搜索代码实际上在对应的list_*.php页面中。
我发现很难找到一种不会使其变得更复杂的设计模式。我发现的大多数都是针对面向对象范式的，而这份清单显然不是。工厂模式当然不会有帮助，因为我发现它的唯一有用的方法是登录（用户名和密码）更改为类似（用户名、密码、ID 号）之类的内容。然而，我认为这不会有用，因为只有 2 个 php 页面具有登录功能。
我还想看看是否所有的搜索逻辑都可以做成一个对象。但是，每种类型的搜索都必须有自己的方法（因为它们正在查询差异表），并且这与当前设置不会有太大不同（每个搜索当前位于相应的列表 php 页面中。
）我发现可能有用的是正则表达式的设计模式。程序中的表格未经验证。在这里你有什么想法吗？
此外，课程的主题是软件质量。我个人的观点是，设计模式会让这个网站变得更加复杂，因为它不是一个大项目。但我的同学认为，由于它不是面向对象的，所以它的可维护性较差。但我在想，PHP 不是 OO 设计的，我对吗？因此，强迫它遵循面向对象的设计模式只会把事情搞砸。
你怎么认为？有可能适用于这种情况的设计模式吗？
We were given a php inventory program. We are then supposed to say if a design pattern will make the program better or if it will just make the program more complicated.
The program is structured like this.
The program is broken down into php scripts embedded with html. Either there is (A) one entire php page dedicated to one option, or (B) an option’s logic is inside another script page that serves for other options of a similar action. (This excludes simple buttons such as “Reset” and “Back to Home.”)
(A) For example, once you open the website, a navigation menu appears with options. When you click an option, say under Customer, there is a “View” link. Once clicked, you are taken to another page that includes other links that corresponds to more options, such as “Edit” and “Delete”. Usually, for this website, each option corresponds to its own php script page. For example, “View” corresponds to list_customers.php. “Edit” corresponds to edit_customer.php.
(B) The other thing that could happen is that the logic for that option is in a “generalized” script page. What I mean by that is that several options’ logic are grouped into one page. An example of this is “Delete.” Before one may delete a customer, a job order, or a quotation, one is directed to a php script page called auth.php to make sure that only the admin may delete. The logic for checking if it’s the admin logging in AND for deleting a customer, a job order, or a quotation is also in auth.php. Another example is all the “Search” option for Customer. Although it has its own page, search_customer.php, the logic for the actually searching is actually in list_customers.php. This pattern follows for all searches, including search for customers, for quotations, or delivery reports; the searching code is actually in the corresponding list_*.php page.
I am finding a hard time finding a design pattern that will not make it more complicated. Most of the ones I find are geared for OO paradigms, and this inventory certainly is not. The Factory Pattern certainly won't help since the only useful way I found it for is if the log in (username and password) changes to something like (username, password, id no.). However, I thought that won't be useful since only 2 php pages have login functionality.
I also looked to see if all the searching logic can be made into a single object. But then, each type of search will have to have it's own method (since they are querying diff. tables), and that wont be much different from the current setup (each search is currently in the corresponding list php page.)
The only thing I found that might be useful is a design patter for regular expressions. The forms in the program are not validated. Do you have any ideas here?
Furthermore, the topic of the class is Software Quality. My personal opinion is that a design patter will make this website more complicated, since it is not such a big project. But my classmates argue that since it's not OO, it is not as maintainable. But I was thinking, PHP was made as not OO, am I correct? So forcing it to conform to an OO design pattern will just mess things up.
What do you think? Any design patterns that might be applicable to this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
设计模式是常见问题的通用解决方案。您使用设计模式并不是为了使用设计模式。您使用它们来解决特定问题。最突出的设计模式来自 GOF 和 POEAA。其中一些很容易实现，例如策略，而另一些则需要更多的架构思想。
您使用的某些设计模式甚至不知道，例如，您的操作脚本对我来说听起来像 TransactionScript 。是的，您可以将它们放入 PageController 中，以减少脚本中的样板代码。然后，您可以添加 FrontController 来减少 PageController 中的样板文件。当您这样做时，为什么不使用 MVC 将业务逻辑和 UI 分开呢？
一般来说，从长远来看，设计模式将使您的代码更易于维护，特别是如果您保留实现GRASP、SOLID 和 DRY。设计模式还将使您的代码更易于理解和讨论，因为模式是定义明确的术语。告诉开发人员这段代码是 Factory，他/她会理解你的。
但是，是的，设计模式也可能使您的代码变得更加复杂，您应该知道在哪里停止以防止过度设计。这并不是说不要使用它们，而是在它们可以解决特定问题的地方合理使用它们。还可以考虑了解常见的AntiPatterns。
由于该课程是关于软件质量的，因此您应该知道软件质量并不是以代码中设计模式的数量来衡量的。软件质量是通过许多指标来衡量的，并且有一些工具可以衡量它们。请查看PHP 项目中的质量保证来了解一下。
顺便说一句，设计模式不一定必须与 OOP 一起使用。 OOP 只是一种组织代码的好方法，许多设计模式确实是针对 OOP 的，但不限于 OOP。 MVC 可以与过程代码一起使用。您可以将策略和工厂与匿名函数一起使用，FrontController 可以是简单的 switch/case 语句，等等。这是因为设计模式是架构蓝图，并且大多与语言和范式无关。
Design Patterns are common solutions to common problems. You dont use Design Patterns to use Design Patterns. You use them to solve a specific problem. The most prominent Design Patterns are those from GOF and POEAA. Some of them are simple to implement, like Strategies, while some others require some more architectural thought.
Some Design Patterns you use without even knowing, for instance, your action scripts sound like TransactionScript to me. And yes, you could make these into a PageController to reduce boilerplate code in the scripts. And you could add a FrontController to reduce boilerplate in the PageControllers then. And while you are at that, why not separate business logic and UI with MVC?
In general, Design Patterns will make your code more maintainable in the long run, especially if you keep your implementations GRASP, SOLID and DRY. Design Patterns will also make your code easier to understand and talk about, because patterns are well defined terms. Tell a developer this piece of code is Factory and s/he will understand you.
But yes, Design Patterns might also make your code more complex and you should know where to stop to prevent overengineering. That's not to say, don't use them, but use them reasonably where they can solve a specific problem. Also consider learning about common AntiPatterns.
Since the class is on Software Quality, you should be aware that Software Quality is not measured in the number of Design Patterns in your code. Software Quality is measured in a number of metrics and there is tools for measuring them. Have a look at Quality Assurance in PHP Projects to get an idea.
On a sidenote, Design Patterns do not necessarily have to be used with OOP. OOP is just a great way of organizing code and a lot of the Design Patterns are indeed targeted at, but not limited to OOP. MVC can be used with procedural code. You can use Strategy and Factory with Anonymous Functions, A FrontController can be a simple switch/case statement, and so on. That's because Design Patterns are architectural blueprints and mostly language and paradigm agnostic.
OO 是一个很好的方法。它确实使代码更易于维护。它确实是编程的未来，而 php 是一种很棒的面向对象语言。
OO is a great way of going. It does make code much more maintainable. It really is the future of programing and php is a great language for OO.
PHP 5+ 相当OO。而且您应该尝试以面向对象的方式完成几乎所有事情，即使它是一页脚本。这里的基本原理是，这一页很有可能会增长或被用于其他用途。
并且不要在没有充分理解设计模式的情况下尝试应用它，当然也不要只是为了称之为模式而将其混入其中。请参阅设计模式上的SO问题。
PHP 5+ is quite OO. And you should try to do mostly anything in an OO manner, even if it's a one page script. The rationale here is that there is a really high possibility that this one page is going to grow or will be used in something else.
And do not try to apply a design pattern without understanding it well, certainly do not mix in a pattern just to call it a pattern. See this SO question on Design Patterns.