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