Object-Oriented Programming for all of us

Let's put vectors, pixels, curves, low level algorithms and related concepts aside for a moment.

A lot of people has been asking me about a more general subject: "You have a software with a lot of low level code. How deep are you using OOP in your project?".

Well ... I have been using OOP in personal and work projects for more than 12 years. I can really give my testimonial about the power of this approach. But how deep can you go? Which effects will you face using OO concepts in deep for low level programming?

There is no doubt about one point: if you really know how to use it, OOP makes programmers life very comfortable. Anyway, nothing is perfect: sometimes what is correct in a OO sense can be not so useful, mainly about performance.

Let's talk about a very generic situation. It's only illustrative, but can be used like an example.

Suppose you have a class "A", which have two operations (methods) "m" and "n". Consider that "A.m" has a time cost of "t", and "A.n" has a time cost of "10000t" (the methods are not necessarily static; it's just for the sake of simplicity). Now, consider that for the correct closure of the state of a object from type "A", I need to call "n" inside the implementation of "m". In this scenario, suppose it's a obligation because an "A" object needs to be correct all time and doesn't know the external environment.

It's much easier make the "A" concept like a class and let each instance of "A" take care about itself. But what about if you use "A.m" in a very inner loop in your source? For each iteration you will pay the price of calling "A.n". Maybe it's too much expensive in time and can make your system useless. In that situation, can be mandatory to break the encapsulation and try to find an algorithm that call "n" source just once (or few times) and let the inner loop run only calling "m" source. This kind of solution can have other bad consequences, but it's another subject.

The final digest is: every big and/or complex software needs a lot of planning and modeling. The "real world" problems sometimes can not be solved using just one paradigm.

In P2P I use a lot of OOP ... but a OO purist would find flaws.