我正在开发一个相当大的 PHP 项目，它以程序化风格编写（它是在 PHP 5 之前编写的），我不禁觉得我正在做的一些事情有点“骇人听闻”。 "其他地方的修改很容易破坏应用程序。我见过的所有设计模式和最佳实践似乎都只适用于 OOP。我可以开始使用 PHP 5 的 OOP 功能编写一些代码，但我不确定是否所有其他开发人员都对 OOP 足够熟悉。
对于更熟悉 OOP 的人来说，只是过程式编程的本质是“骇人听闻”吗？是否有“最佳实践”书籍涉及如何保持大型程序应用程序的可维护性并降低引入新错误的可能性？
我知道我可以以程序方式应用 OOP 设计原则/模式，但如果我要这样做，我还不如只使用 PHP 的 OOP 功能。也许我只是对程序范式的理解不够好？
【问题讨论】：
标签： php design-patterns procedural-programming
过程式编程，尤其是在 PHP 中，没有具体的“封装”概念——一切都可用，只是修改它不是你的工作，所以你不需要。对于那些除了 OOP 什么都不知道的人，或者被教导程序代码是 BAAAAAAD 的人，是的，它看起来很老套和错误。但人们已经这样做了很长时间，而且确实有效。
现在，您很可能发现了一些实际上很糟糕的程序代码。糟糕的 OOP 代码与它一样多。
过程代码的基本实践与 OOP 并没有太大的不同——尽可能避免使用全局变量，将相关函数组合在一起并尽量缩短它们。本质上并没有真正的“模式”，因为过程编程比模式运动早了几十年。但是干净的程序代码不必像 OOP 狂热者所相信的那样丑陋。
【讨论】：
我的程序代码实际上看起来很 OOish。很多时候我有传递复合结构的函数，例如$页。如果需要，这将使任何 set_title($page, $title) 转换为 $page->set_title($title) 变得非常简单。这只是一种不同的表示法，这些方法完成的内容没有实际区别。
设计模式是一个广泛的领域。如果应用于程序代码，肯定会有一些看起来很傻的事情。坦率地说，一些 OOP 设计模式在基于类的代码中也不是很明智。但是，如果有重写继承代码库的明确用例，请尝试一下。我怀疑你的合作程序员对对象结构化接口过敏。
听起来好像您的应用程序中的问题源于陈旧而复杂的结构。如果它是用 PHP3 风格编写的，例如仍然使用 $HTTP_GET_VARS，那就不要尝试了。然而，如果它只是全局变量和独立的代码状态，那么引入一些对象结构是可行的。
PS：全局变量：OOP 中的单例只是过于复杂的全局变量。大多数应用程序需要一组配置设置（只是读取，从不写入）。这些属于全局对象或数组。其他一切都很危险。
【讨论】：