过程编程的设计模式和封装？
我正在开发一个相当大的以过程风格编写的 PHP 项目（它是在 PHP 5 之前编写的），我不禁觉得我正在做的一些事情有点“hackish”。其他地方的修改很容易破坏应用程序。我见过的所有设计模式和最佳实践似乎只适用于 OOP。我可以开始使用 PHP 5 的 OOP 功能编写一些代码，但我不确定所有其他开发人员是否都足够熟悉 OOP。
对于更熟悉 OOP 的人来说，过程式编程是否显得“老套”？是否有“最佳实践”书籍介绍如何保持大型程序应用程序的可维护性并减少引入新错误的可能性？
我知道我可以以过程的方式应用 OOP 设计原则/模式，但如果我要这样做，我还不如使用 PHP 的 OOP 功能。也许我只是对程序范式没有足够的理解？
I'm working on a fairly large PHP project written in a procedural style (it was written before PHP 5), and I can't help but feel that some of the things I'm doing are a little "hackish." A modification somewhere else can easily break the application. All the design patterns and best practices I've seen seem to only apply to OOP. I could start writing some of my code using PHP 5's OOP features, but I'm not sure if all the other developers are familiar enough with OOP.
Is it just the nature of procedural programming to seem "hackish" to people more familiar with OOP? Are there "best practices" books that deal with how to keep large procedural applications maintainable and make the introduction of new bugs less likely?
I know I could apply OOP design principles/patterns in a procedural way, but if I was going to do that, I might as well just use PHP's OOP features. Maybe I just don't have a good enough understanding of the procedural paradigm?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
过程式编程，尤其是在 PHP 中，没有具体的“封装”概念——一切都可用，只是修改它不是你的工作，所以你不需要。对于那些除了面向对象编程之外一无所知的人，或者被教导过程代码是糟糕透顶的人来说，是的，它可能看起来很黑客且错误。但人们已经这样做了很长时间，而且确实有效。
现在，您很可能发现了一些实际上很糟糕的过程代码。糟糕的 OOP 代码就有多少。
过程代码的基本实践与 OOP 没有太大不同——如果可能的话，避免全局变量，将相关函数组合在一起并尽量保持简短。本质上并不存在真正的“模式”，因为过程编程比模式运动早了几十年。但干净的过程代码不必像 OOP 狂热者让您相信的那样丑陋。
Procedural programming, especially in PHP, doesn't have a concrete notion of "encapsulation" -- everything's available, it's just not your job to modify it, so you don't. To those who don't know anything but OOP, or were taught that procedural code is BAAAAAAD, yes, it can look hackish and wrong. But people have been doing it for a LONG time, and it does work.
Now, it's just as likely that you've found some of the ACTUALLY bad procedural code. There's as much of it as there is bad OOP code.
Basic practices for procedural code aren't a whole lot different than for OOP -- avoid globals if possible, group related functions together and try to keep them short. There aren't really "patterns", per se, as procedural programming predates the patterns movement by a few decades. But clean procedural code need not be as ugly as the OOP zealots would have you believe.
我的程序代码实际上看起来很 OOish。我经常使用传递复合结构的函数，例如 $page。如果需要的话，这将使将任何 set_title($page, $title) 转换为 $page->set_title($title) 变得非常简单。这只是一种不同的表示法，这些方法所实现的功能没有实际差异。
设计模式是一个广阔的领域。如果应用于过程代码，有些事情肯定会看起来很愚蠢。坦率地说，一些 OOP 设计模式在基于类的代码中也不是很明智。但是，如果有一个明确的用例可以重写您继承的代码库，请尝试一下。我怀疑你的同事程序员对对象结构接口过敏。
听起来您的应用程序中的问题似乎源于陈旧且复杂的结构。如果它是用 PHP3 风格编写的，例如仍然使用 $HTTP_GET_VARS，那么就不要尝试。然而，如果它只是全局变量和独立的代码状态，那么引入一些对象结构是可行的。
PS：全局变量：OOP 中的单例只是过于复杂的全局变量。大多数应用程序需要一系列配置设置（仅读取，从不写入）。它们属于全局对象或数组。其他一切都很危险。
My procedural code looks quite OOish actually. Quite often I have functions that pass around a compound structure, e.g. $page. And that would make it quite simple to transition any set_title($page, $title) into $page->set_title($title) if needed. It's just a different notation, there is no practical difference in what the methods accomplish.
Design patterns is a wide field. There are certainly things that will look silly if applied to procedural code. And frankly, some OOP design patterns are not very sensible in class based code too. But if there is a clear use case for rewriting your inherited code base, give it a try. I doubt your fellow coprogrammers are allergic to object-structured interfaces.
It sounds as if the problems in your application stem from the aged and convoluted structure. If it was written in PHP3 style, e.g. still uses $HTTP_GET_VARS, then don't try. If it's however just global variables and inderdependent code state, then bringing in some object-structure is doable.
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.