何时从过程式切换到 OOP？
在大多数关于 OOP 的讨论中，都说它的优点是可重用性。您投入了一些额外的工作来定义您的类，这可以节省您以后创建这些对象的许多实例和扩展的时间。
由此得出的一个推论似乎是，在将所有内容写入对象的权衡与节省的时间相当之前，您不应该从过程编程切换到 OOP 编程。
一般来说，什么时候是从过程编程切换到 OOP 编程的好时机？您通常会寻找任何迹象/特征来了解您的项目需要进行这种转换吗？
In most discussions of OOP it's said that the advantage is re-usability.. You put in some extra work to define your classes, and it saves you time later in being able to create many instances and extensions of those objects.
A corrolary of this seems to be that you shouldn't switch from procedural to OOP programming until the tradeoff of writing up everything into objects is equivelant to the time you'll save.
In general, when is a good time to switch from procedural to OOP programming? Are there any signs/characteristics you generally look for to know your project needs to make that switch?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我假设这个问题是从初学者的角度/范式提出的。一旦程序员有了编写面向对象代码的经验，您当然可以使用这种架构从头开始编写一个项目。事实上，我认为自上而下的方法可以为您在大型项目上节省大量时间。
不过，对于你概述的自下而上的场景，我想说你必须去感受一下。一般而言，请参阅这篇维基百科文章，了解有关不同方法的更多信息。
具体到 PHP，我想说你可以使用这种方法进行迁移：
相关功能）并放置它们
到包含文件中。
这个过程是了解 OO 细节的好方法，最终您将看到好处。它还将告诉您我的最初观点：将某些东西转换为面向对象所需的时间比从一开始就进行表面上的良好（高阶）设计所需的时间要长得多。
I'm assuming this question is from the standpoint/paradigm of being a beginner. Once a programmer has experience writing object-oriented code, you can certainly author a project from the beginning using this architecture. In fact, I'd argue that a top-down approach can save you huge amounts of time on larger projects.
For the bottom-up scenario you outline, though, I'd say you'd have to feel it out. Reference this wikipedia article for more information about the different approaches, generically speaking.
Specific to PHP, I'd say you could use this approach for a migration:
related functions) and place them
into include files.
This process is a great way to learn the ins and outs of OO, and in the end you will see the benefits. It will also teach you my initial point: that it takes a lot longer to convert something into OO than it does to start with a semblance of good (high-order) design from the beginning.
如果它不是一个非常非常简单的应用程序，那么现在就是时候了。事实上，您是否应该始终进行面向对象编程是有争议的，因为当您将来想要扩展程序时会变得更加困难。
If it's not a very very simple application, now is the time. In fact, it's arguable that you should always program OOly, because it will be harder when you want to extend your program in the future.
我认为这取决于上下文。对于使用现有 OOP 框架的图形应用程序，权衡是即时的——在某些情况下，您必须不遗余力地编写过程 GUI 代码。
但是，如果您正在进行原始数据处理并且不与任何 OOP 框架进行互操作，也许您会发现 OOP 永远没有意义。
I think it depends on the context. For graphics applications using an existing OOP framework, the tradeoff is instantaneous -- you'd have to go out of your way to write procedural GUI code in some contexts.
However, if you're doing raw data processing and not interoperating with any OOP framework, maybe you'd find that OOP never makes sense.
在项目中切换到 OOP 可能非常耗时。我怀疑它是否会有利可图，因为它需要大量的编码、大量的测试，然后进行大量的重构。 OOP的整个概念与PP不同。
所以我建议不要在项目内切换，而是尽快开始在新项目中使用 OOP。当您感觉舒服时，您可以开始考虑现有项目的 OOP 设计，并逐步实现 OOP 中的功能。不过，这将是大量工作，而且可能感觉像是重写整个项目。
It may be very time-consuming to switch to OOP withing a project. I doubt it would be profitable, because it requires a lot of coding, a hell of a lot of testing, and then a LOT of refactoring. The whole concept of OOP is different from PP.
So I would recommend not to switch within the project, but start using OOP for new projects as soon as possible. When you feel comfortable, you can start thinking of an OOP design for your existing project(s) and gradually implement features in OOP. It will be a lot of work, though, and it will probably feel like rewriting the entire project.
我会在其他地方寻找您需要转换的迹象。对于所有的炒作——而且我是 OOP 的大力支持者——OOP 语言的代码重用通常只是稍微好一点。
OOP 是另一种帮助组织代码的简单工具，就像过去的函数一样。这是一个很棒且有用的工具。但主要的好处是使编写和维护代码变得更容易。
如果是我，并且转向 OOP 几乎需要完全重写，那么我会推迟，直到转换的更多实质性好处变得明显。如果你的代码有效，我不知道你为什么要重写它。
I would look elsewhere for signs you need to switch. For all the hype--and I'm a big supporter of OOP--code reuse is often only marginally better with OOP languages.
OOP is simple another tool to help organize your code, like functions in the past. It's a great and useful tool. But the main benefits are making it easier to write and maintain your code.
If it were me and moving to OOP required almost a complete rewrite, I'd hold off until some more material benefits of the switch became apparent. If your code works, I don't know why you'd rewrite it.
这取决于任务，但完成这两项任务后，我会考虑以下问题：
您认为这项工作需要模块化吗？从中心位置管理相似或不同事物的能力？是否有很多重复元素？快速开发或管理变更重要吗？
您认为您正在解决的问题是可预测的且重复的吗？该任务最好是通过以下步骤来解决还是通过应用算法来完成？
如果更像 1，那么就采用 OOP，否则如果更像 2，那么就采用过程方法。
如有疑问，请使用您觉得舒服的东西。
It depends on the task, but having done both, here's what I would think about:
do you feel the work requires modularity? the ability to manage similar or dissimilar things from a central place? are there many repeating elements? will quick development or administration changes be important?
do you feel the problem you are attacking is predictable and repetitive? is the task best served by following steps to solve or by applying algorithms?
If more like 1, then go for OOP, otherwise if it's more like 2, then go for a procedure approach.
When in doubt, use what you're comfortable with.
改变正在进行的项目的编程风格很少是一件好事。
如果您希望实体之间的职责更加明确，您始终可以将面向对象原则应用于过程代码。
例如，检查这本非常有趣的书，介绍 ANSI-C 中的 OO 编码
It is rarely a good thing to change the programming style of an ongoing project.
You can always apply OO principles to procedural code if you want more clear-cut responsabilities among your entities.
check for instance this very interesting book on OO coding in ANSI-C