When to switch from procedural to 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?

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:

1. Take as much code as you can (ie: related functions) and place them into include files.
2. Create a container class for that file. You can start with just using all the functions by calling them in a static manner, or even using a static (singleton) class.
3. Gradually convert to an instance paradigm instead of the global data / static function one that is the badness of procedural programming.

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.

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.

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.

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.

It depends on the task, but having done both, here's what I would think about:

1. 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?

2. 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.

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