Thursday, January 6, 2011

OOP, a marketing lie?

In commercials, we are told a lot of lies. For example, some ads say that carbon has 10 times better strength to weight ratio than aluminum. Yet bicycles made from carbon, though not having even twice less weight than aluminum ones, break into pieces more often. The ads forget to tell that they tested the strength only in one direction, and the test has no relevance in reality.

We are told that OOP makes software easier to develop, document and maintain.

But, contrary to this, I find that when doing OOP, I need to think a lot more when I start to write new code, where should I put this code, and how the classes should be organized. In procedural programming, the organization comes naturally, I start with a procedure, and add subprocedures until it is finished.

So, what's the reason for this seeming contradiction? Why is almost everybody using OOP?

The reason for OOP is not because we can write a 3 man-year OOP program easier than a procedural one. For these small projects, I think that procedural programming is faster.

The real reason for OOP is procedure names in big APIs. If .NET would have a procedural API, they've had a lot of headache coming up with good procedure names. And even if the API writers would come up with some names, a huge flat/procedural API would be harder to use than an object-oriented one. (The user would need to learn a lot more names, procedure names, instead of class names.) While the APIs were small (i.e. Turbo Pascal), it was easier to come up with good procedure names, than coming up with classes.

The whole story is similar to that of the file system. That is, DOS 1.0 did not have directories, because they were an unneeded complication, when the files were few.