tags:

views:

143

answers:

4

I am developing a project in C++. I realised that my program is not OO.

I have a main.cpp, and several headers for different purposes. Each header is basically a collection of related functions with some global variables to retain data. I also have a windowing.h for managing windows. This contains the winMain() and winProc(). It calls the functions that resides in my main.cpp when events happen (like clicking a button) or when it needs information (like 'how big to make this window?'). These functions are declared in a seperate .h file included into windowing.h.

Is it worth changing this to be OO? Is it worth the work. Is there any better way I can construct the program without too many changes?

All feedback welcome, thankyou for taking the time to read this.

+6  A: 

No, I think if it ain't broke, don't fix it.

Any windowing system is inherently OO to a degree. You have a handle to a window managed by the OS, and you can perform certain operations on it. Whether you use window->resize() or resize(window) is immaterial. There is clearly no value in such syntactic rearrangement.

However, as the application grows, you will likely find that many windows are mostly similar and subtly different. The best implementation is boilerplate basic functionality with special functions attached. And the way to do that is with a base class and polymorphism.

So, if you can refactor the program to be more elegant with OO, go for it. If it grows into the OO paradigm with natural evolution, follow best practices and let it be so. But don't just try to be buzzword-compliant.

Potatoswatter
+1  A: 

It depends on what you want to accomplish with the project. If not using the OO features of C++ works for you and there are no good reasons to change, then keep going the way you're going. If, on the other hand, you would like to learn more about OOP and you have the time to apply to it, refactoring it to be more OO style will provide you with a great learning opportunity.

andand
+1  A: 

I would follow the best practices for working with whatever window manager you are using. Most use an OO style, which you'll automatically inherit (!) as you follow its usage patterns.

Graham Perks
+2  A: 

Two things you need to think about: cost/benefit analysis and opportunity cost.

What is the cost of changing your code to be OO? What is the benefit? If the latter outweighs the former, then I'd tend towards changing it.

Costs include traditional costs such as time spent, money spent and so on. Benefits include a cleaner implementation, leading to easier maintenance in future. Whatever other costs and benefits there are depend really upon your own situation.

But one thing often overlooked is the opportunity cost. This is a cost that should be factored in to your analysis. It's an economic term meaning foregone opportunities.

In other words, if you do convert your code, your cost includes your inability to do something else with that time.

Classic example. If you do the conversion and a customer decides to not buy your software because you're not adding the feature they want, that lost sales opportunity is a cost.

paxdiablo
Interesting point. My code would look prettier by changing it to OO, but I wouldn't gain much functionality.
Alexander Rafferty
Functionality isn't everything, and prettiness of code is irrelevant. Maintainability of code _is_ relevant and pretty code may be more maintainable but that's not always a given.
paxdiablo