程序编程的设计模式和封装？
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?
我正在研究一个以程序风格编写的相当大的PHP项目（它是在PHP 5之前编写的）， 而且我不禁觉得我正在做的一些事情有点“狡猾”。 其他地方的修改很容易破坏应用程序。 我见过的所有设计模式和最佳实践似乎只适用于OOP。 我可以使用PHP 5的OOP功能开始编写我的一些代码，但我不确定所有其他开发人员是否都熟悉OOP。 p>
这是程序编程的本质吗？ 对那些更熟悉OOP的人来说，似乎是“hackish”？ 是否存在“最佳实践”书籍，这些书籍涉及如何保持大型程序应用程序的可维护性，并且不太可能引入新的错误？ p>
我知道我可以将OOP设计原则/模式应用于 程序方式，但如果我要这样做，我不妨使用PHP的OOP功能。 也许我对程序范式没有足够的理解？ p> div>
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.
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.