Data Mapping and Moving Relationships
Despite being some sort of an OOP fan, I cannot be completely oblivious to its limitations... or shortcomings... or perhaps some lack of foresight in its design. You choose.
There are two issues that always made me reevaluate OOP usefulness. I'm going to discuss them. You, of course, are free to ignore me completely, or provide your insight into the discussion. The reason why I'm doing this is because I never before discussed this issue with anyone. All tidbits of info I read here and there had always been addressed by zealots of either the OOP or Anti-OOP fields, which invariably come strongly biased.
Relational Data Mapping
OOP always was, and still is, a mystery to me. But of all the mysteries, the one I took longer to understand was OOP lack of capacity to establish relational links between data. I mean, everything in OOP screams relations and yet the universe at which this happens is completely different from that of Relational Databases. It's a little like Einstein trying to grab electromagnetism and add gravity to produce an unified rule. It won't happen. Relational Databases and OOP have completely different rules and operate at completely different levels, even if the idea of joining them or trying to find a common place among them may seem appealing.
The very first problem I encountered was trying to achieve with OOP the same level of atomicity expressed by relational databases. I don't think I'm the only one who has ever tried before to simply write a class that translated directly to a relational database table, names and everything, only to have to scratch the design as soon as I tried to express in code the relationships between the tables of the database. What is funny is that it took me a long while to finally understand that the sad truth is that OO design doesn't map well to Relational Data. When I finally did, I felt like Einstein on a bad day.
OOP atomicity is at the class level. Not that of the data member. The amount of effort needed to translate data rules to OOP is high. So high, that it is clearly telling us to stop right there. That is not what OOP was designed for. And this is probably what some OOP defacers don't realize. These are two distinct universes. At first sight the Einsteins may think there is a relationship between them. But... there isn't.
Wish: I wish OOP evolves one day to have the necessary constructs to map directly to relational data.
Moving (Dynamic) Relationships
But if the above is not enough, and someone still insists it is possible to express those kind of relationships (some OOP fans do really believe OOP is the solution to everything), he will be happy to show up with a neat (albeit rather complex) system of classes, interfaces, and whatnots to prove me wrong.
I could perhaps point out the complexity of the code or the time spent for something that is expressed by SQL in 10 or so lines. But that would still lead to debate. As such, all I had to do was to change one of the database rules, to completely destroy his entire design.
OOP is pretty much static. Once the rules are laid out, nothing ever changes. One of the problems of OOP is the fact we need to code with this in mind. OOP defacers point out, perhaps with some reason, if I want to program with change in mind I will end up with a completely different design than that where I didn't expect any changes. But adding to this, we cannot cope with every possible change that may happen in data rules. We can expect a new department to be added to the company. But can we expect Human Resources to move under the direct supervision of the Board for a period of 6 months?
Furthermore, changes in data rules invariably lead to changes in code. There is no way around it. OOP is static and it must conform to the rules in a given period of time. It's easier to predict additions and omissions. But it's much harder to predict, and almost (if not at all) impossible to express, changes in rules.
Wish: I Wish OOP one day adds specific structures capable of expressing ad-hoc relationships.
The best argument against my wishes is how I started them; "OOP is not designed for that". However, I wonder how much of that would be possible.
Granted I never did much reading on these issues. However I don't think it's anyone plan to say OOP is finished, we did all we had to do, and it's the perfect tool for its job. I expect the paradigm to evolve (even if we haven't seen much of that lately) and conform to the demands of an industry that keeps moving towards the future.
OOP lacks abilities to which it wasn't designed for. The question is though, can it add that functionality?