Obstacle Oriented Programming II
This is a response to my previous post about OOP, over a year ago.
As I’m developing my own programming language, I’ve read a lot of documentation about procedural, relational and object oriented programming. Because of this newly acquired knowledge I’ve got to tune down last year’s attack on OOP. Lots of arguments are still valid, though.
Object oriented programming, as I’ve stated last year, has it’s uses. It’s not the holy grail. Not even close. OOP only works well when structures within the software are static in the real world. Following many of the examples in OOP books for instance, inheritance is explained by a car analogy. Of course car parts don’t change their order of, or dependance upon each other. But in the real world this does happen quite a lot. It’s hard and sometimes even impossible to restructure your code to reflect real-world structural changes when using the OOP model. It often requires rewriting much of the OOP wrapping code.
My previous ranting crusade against all that was OOP was a little mislead. All the OOP code I’ve worked with was primarily PHP code. PHP doesn’t support OOP. It tries to, just like it tries everything else, but fails. Just like at everything else PHP tries. Most of the C++ code I’ve worked with has been developed by fellow students. Not that I want them to take the blame for my anti-OOP stance of yesteryear, but their code has contributed to the negativity. I won’t blame them, it’s the teachers who don’t understand a single OOP concept. They only know how the language works grammatically but fail to translate the grammar to real world problems. So students just end up recreating all the stupid examples in their software the teachers conjured up.
The worst thing is, these students end up writing code in big code generating companies like Logica or Atos Origin. The cubicle philosophy is worshipped like burgers at Mc Donald’s. At these companies the code is just a byproduct. It’s the entire package they’re interested in. The V-model is followed by the letter and engineers are happy they can go home to their normal life, wife and kids at 5pm. This byproduct of theirs is sent into space, embedded into medical devices or used at your bank. Most of the IT flaws seen today can be blamed upon nobody telling these people how to write proper OOP, let alone proper code.
I know what you must be thinking. What the f*ck made this guy change his mind? Qt. If you want to know how a proper C++ OOP model looks like, look no further. Qt makes programs less complicated, it just does everything right. Alright, some aspects (like the dreadful Qt4 CSS) need some polishing, but overall Qt is a prime example. It’s documented properly, has a sane object structure and actually makes sense.
I don’t like languages that make everything behave like an object. It’s not easier for the developer, it introduces unnecessary overhead and often makes the program overly complicated when writing binary handling software like, say, file or socket streams. A file handle is an object, but fully privatised. Just remember what you’re abstracting. I also still hate database object mapping. For example Ruby on Rails rapes the database that way. Why would you need to convert table data to a language specific storage format just to convert it again to database objects? It takes at least twice the amount of data processing and, depending on your language of choice, sometimes twice as much memory. There’s no real good way to really tune your software for a certain DBMS. Database abstraction is evil, just learn proper SQL and procedural data type abstraction.
Finally I’d like to address the OOP in PHP topic. Of course you can write OOP using PHP. You’ve got two choices, really. You can use PHP objects and risk to stumble upon one of the many pitfalls it brings to the table. Or do it the Linux way. Much of the Linux kernel, and especially the API, has many OOP features but doesn’t use real objects. Of course these handles behave like objects, and in essence they are, but they’re implemented using C. You can use this technique to your advantage when designing PHP software. Use array-based handles and use the global scope in a civilised manner.
Discussion Area - Leave a Comment