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