对于这个项目来说，哪个更好，过程化还是面向对象？
我一直在研究图像加载/缓存系统的许多试验/错误版本。作为 Delphi 的一员，我一直对面向对象编程很满意。但自从我开始实现一些多线程以来，我一直在想也许这个系统应该在程序基础上工作。
为什么是因为这些进程将被踢入线程池，进行图像的脏加载/保存，并释放自己。当我只能使用过程/函数、记录、事件和图形时，我一直试图将这些线程进程包装在对象内。当所有内容都在一个单元内时，无需将其全部包装在一个类中......对吗？
现在我问的一个主要原因是因为该系统是在设备底部初始化的。当使用 OmniThreadLibrary (OTL) 时，它已经有自己的初始化线程池，我什至不需要初始化我的线程池。
那么哪种方法更适合这个系统 - 包装在对象内，或者只是在单元内运行，为什么？有没有多线程的例子，没有将任何东西包装在对象内部，而是在单元中？
I've been working through many trial/error versions of an image loading/caching system. Being Delphi, I've always been comfortable with Object Oriented Programming. But since I've started implementing some multi-threading, I've been thinking that maybe this system should work on a procedural basis instead.
Why is because these processes will be kicked into a thread pool, do the dirty loading/saving of images, and free themselves up. I've been trying to wrap these threaded processes inside objects, when I could just use procedures/functions, records, events, and graphics. No need to wrap it all inside a class, when it's all inside a unit... right?
Now one main reason I'm asking is because this system is initialized at the bottom of the unit. When using the OmniThreadLibrary (OTL), it already has its own initialized thread pool, and I don't even need to initialize mine either.
So which approach is better for this system - wrapped inside an object, or just functions within the unit, and why? Any examples of multi-threading without wrapping anything inside an object, but in the unit instead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您有单身人士，那么这归结为个人喜好问题。以下是我的一些想法：
最重要的是，这并不重要，您必须选择最适合您的项目的内容。
If you have a singleton then it boils down to a matter of personal preference. Here are some thoughts of mine:
Bottom line is that it doesn't really matter and you have to pick what fits best in your project.
OOP 并不意味着您需要为所有内容创建新对象。您也可以简单地从现有对象继承。 （就像 OTL 的任何线程对象一样）
无论如何，我并不热衷于到处引入 OO，但我在您的文本中看不到任何需要过程的原因。
OOP doesn't mean you need to create new object for everything. You can simply inherit from existing objects too. (like the whatever thread object of the OTL)
Anyway, I'm not exactly rabid in introducing OO everywhere, but I don't see any reason in your text why procedural would be needed.
无论如何，这都不是一个是/否的决定。
我倾向于使用不属于类的函数和过程，当它们所做的工作与任何状态无关，并且当它们旨在有用并单独重用时，例如它们中的实用字符串函数的情况自己的公用事业单位。您可能会发现您需要“图像实用函数”，并且它们不需要位于类中。
如果你的函数只在后台线程的上下文中运行，那么它可能属于 TThread 后代，如果它不被前台调用，它可以是私有的，这使得 OOP 及其范围隐藏功能非常重要适合线程编程。
我的经验法则是：如果您没有从以某种真正的方式使其成为独立函数/过程中受益，那么就不要回到非 OOP 过程。
有些人如此热衷于 OOP，以至于他们避免使用非 OOP 函数和过程，并且喜欢为所有内容使用类包装器。我称之为“Java 代码味道”。但没有理由避免 OOP。它只是一个工具。在有意义的地方使用它。
It's not a yes/no decision by any means.
I tend to use functions and procedures that are not part of classes, when the work they do has nothing to do with any state, and when they are intended to be useful and reused separately, such as is the case for utility string functions in their own utility unit. You might find you need "Image Utility Functions" and that they do not need to be in a class.
If your function only runs in the context of a background thread, then it probably belongs to a TThread-descendant, and if it's not to be called by the foreground, it can be private, making OOP, and its scope-hiding capabilities very much apropos for thread programming.
My rule of thumb is : If you don't benefit from making it a standalone function/procedure in some real way, then don't go back to non-OOP procedures.
Some people are so into OOP that they avoid non-OOP functions and procedures, and like to have class wrappers for everything. I call that "Java code smell". But there is no reason to avoid OOP. It's just a tool. Use it where it makes sense.