过程性编程的设计模式和封装？

Question

我正在做一个用过程化风格编写的相当大的PHP项目(它是在PHP5之前编写的)，我不禁觉得我正在做的一些事情有点“hackish”。其他地方的修改很容易破坏应用程序。我所见过的所有设计模式和最佳实践似乎都只适用于OOP。我可以开始使用PHP5的OOP特性编写我的一些代码，但我不确定是否所有其他开发人员都足够熟悉OOP。

对于更熟悉OOP的人来说，这仅仅是过程化编程的本质吗？是否有“最佳实践”书籍处理如何保持大型过程性应用程序的可维护性，并降低引入新bug的可能性？

我知道我可以以一种过程化的方式应用OOP设计原则/模式，但如果我要这样做，我还不如使用PHP的OOP特性。也许我对程序范例的理解还不够好？

Answer 1

过程性编程，特别是在PHP中，没有具体的“封装”概念--一切都是可用的，只是修改它不是您的工作，所以您不需要。对于那些除了OOP之外一无所知的人，或者被教导过程代码是愚蠢的人来说，是的，它看起来有点老套和错误。但人们已经这样做了很长一段时间，它确实起作用了。

现在，你很可能已经发现了一些糟糕的过程代码。它的数量和糟糕的OOP代码一样多。

过程代码的基本实践与OOP没有太大不同--尽可能避免使用全局变量，将相关函数分组在一起并尽量保持简短。就其本身而言，并没有真正的“模式”，因为过程编程比模式运动早了几十年。但是干净的过程代码不需要像OOP狂热者希望你相信的那样丑陋。

Answer 2

实际上，我的过程代码看起来相当OOish。我经常使用传递复合结构的函数，例如$page。如果需要，这将使得将任何set_title($page，$title)转换为$page->set_title($title)变得非常简单。这只是一种不同的符号，在方法完成的内容上没有实际区别。

设计模式是一个广泛的领域。如果应用到过程代码中，肯定会有一些事情看起来很愚蠢。坦率地说，一些OOP设计模式在基于类的代码中也不是很明智。但是，如果有一个明确的用例可以重写继承的代码库，那就试一试。我怀疑你的同事是不是对对象结构接口过敏。

听起来你的应用程序中的问题似乎源于陈旧和错综复杂的结构。如果它是以PHP3风格编写的，例如仍然使用$HTTP_GET_VARS，那么不要尝试。然而，如果只是全局变量和内部依赖的代码状态，那么引入一些对象结构是可行的。

PS:全局变量: OOP中的单例只是过于复杂的全局变量。大多数应用程序需要一组配置设置(只读，不写)。它们属于全局对象或数组。其他的都是危险的。