哪个更适合这个项目，程序或面向对象？

Question

我一直在研究图像加载/缓存系统的许多试用/错误版本。作为Delphi，我总是对面向对象编程感到满意。但是自从我开始实现一些多线程之后，我一直在想这个系统应该在程序基础上工作。

为什么是因为这些进程会被踢进一个线程池，进行脏加载/保存图像，然后释放自己。当我只能使用过程/函数，记录，事件和图形时，我一直在尝试将这些线程进程包装在对象中。没有必要将它全部包含在一个类中，当它全部在一个单元内时......对吗？

现在我要问的一个主要原因是因为该系统在设备底部初始化。使用OmniThreadLibrary（OTL）时，它已经有了自己的初始化线程池，我甚至不需要初始化它。

那么哪种方法对于这个系统更好 - 包裹在一个对象内部，或者仅仅是单元内的功能，为什么？任何多线程的例子都没有在对象内包装任何内容，而是在单元中包含？

Answer 1

如果你有一个单身人士，那么归结为个人偏好。以下是我的一些想法：

• 如果你的代码库的其余部分使用OOP，那么使用procedural可以使这段代码看起来很奇怪。
• 如果使用OOP，则可以使用属性，默认属性，数组属性。这可以使您的界面更有用。
• 将您的功能放入类中可以为您提供额外的命名空间级别。你可能会也可能不会欣赏它。
• 如果你需要维护很多具有全局范围的状态，那么你可能会把它包装成一个记录。您将拥有在此全局记录实例上运行的函数。此时代码将更好地用对象语法编写。

底线是它并不重要，你必须选择最适合你项目的东西。

Answer 2

OOP并不意味着您需要为所有内容创建新对象。您也可以简单地继承现有对象。 （就像OTL的任何线程对象一样）

无论如何，我并不是在向所有地方介绍OO时都很狂热，但我认为你的文本中没有任何理由需要程序化。

Answer 3

这绝不是一个是/否的决定。

我倾向于使用不属于类的函数和过程，当它们所做的工作与任何状态无关，并且当它们打算有用并单独重用时，例如实用程序字符串的情况功能在他们自己的实用单元中。您可能会发现需要“图像实用程序功能”，并且它们不需要在类中。

如果你的函数只在后台线程的上下文中运行，那么它可能属于一个TThread-descendant，如果它不被前景调用，它可以是私有的，制作OOP，并且它的范围隐藏能力非常适合线程编程。

我的经验法则是：如果你没有以某种真实的方式使它成为独立的功能/程序，那么就不要回到非OOP程序。

有些人对OOP有这样的看法，他们避免使用非OOP函数和过程，并且喜欢为所有东西创建类包装器。我称之为“Java代码味道”。但没有理由避免OOP。这只是一个工具。在有意义的地方使用它。