Which is better for this project, procedural or object oriented?

Question

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?

Answer 1

If you have a singleton then it boils down to a matter of personal preference. Here are some thoughts of mine:

• If the rest of your codebase uses OOP then use procedural could make this code look and feel odd.
• If you use OOP you can use properties, default properties, array properties. That could make your interface more useable.
• Putting your functionality into a class gives you an extra namespace level. You may or may not appreciate that.
• If you need to maintain a lot of state with global scope then you'll probably wrap it up into a record. And you will have functions that operate on this global record instance. At which point the code would read better written with object syntax.

Bottom line is that it doesn't really matter and you have to pick what fits best in your project.

Answer 2

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.

Answer 3

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.