Quote Originally Posted by yrwyddfa
Now we get to the interesting part. What comes next? If you are an OO fan then you are going to write a translation layer. You are going to convert one high level model into another. Why? The relational model has proved itself over many decades and is both a mathematical and commercial success. What’s wrong with implementing software against the relational model? Why do you want to convert your data into another high-level model? If you were honest you’d probably admit that you do it because either you were told it was the best way to do it, or simply read it on some website or in a book.
Absolutely honest now: no.

Why would I convert one high-level abstraction into another? Because abstractions always come with trade-offs. That's a fact: to combine two concrete cases into one abstraction, you must discard some of the differences between the cases.
Different abstractions have different trade-offs. As such they are useful for different applications. The relational model is wonderful for data storage, but I don't want to even begin thinking about programming a larger application completely against data in third normal. Functional programming languages like Haskell or XSLT are very cool for data transformations of all kinds, but making them interact with a user gives me headaches. Object-oriented imperative languages are not too bad (though rather unstructured) at data storage, but are really bad for data transformation, but they are wonderful for building a GUI out of components. (You'll find that things in OOP languages that deal with data transformation tend to look very functional, or else to be completely unreadable.)

The rest of the layers are pretty much unimportant for this discussion, but the whole list (for an OO system) is something like this: RDBMS, data-access, Relational/Object Mapping, Business Logic, GUI. Of course, different people do things in slightly different ways, but nevertheless this is a realistic example of an n-tier system
A peculiar thing happened with n-tier systems and their domain objects. They have become very close to structs. A domain object usually is responsible only for storing its data, ensuring its own data integrity and possibly load (or rather request loading of) associated data.
What does that mean? I don't know. But it's definitely a move back towards the procedural model.

It should be self evident that mutual storage at high levels of abstraction of both the data, and behaviour is simply not a good idea.
I'm afraid it's not at all self-evident. Why is it a bad idea?

I can hear the religious fervour of those who have already fallen for the seductive delights of the PhD driven software revolution (also known as scientific drivel)
I don't believe in such a thing as a "PhD-drived software revolution". Software development is, despite managerial intervention, still at its roots a Mendelian environment. OO has fared well. For a paradigm to reach a popularity where it can gain managerial support, it must be good, or else it will die before a manager ever hears of it.

But can’t you see? This is such a bad idea. Such a terrible disgusting idea that it should never be allowed by law. There should be statutes written and discussed in the political institutions the world over to prevent people from doing this.
How come? What on earth are you talking about?

Inheritance is evil. There has been a massive increase in the number of technologies sold, and/or implemented that allow the decoupling of systems from each other. I spend a fair degree of time protecting my user’s data from hardware failure, or integration failure. The classic way of doing this is to use a temporary store such as queue, so that if the target hardware fails, when it recovers (or you buy new hardware) the software continues to process the contents of the queue and the data is safe.
This has nothing at all to do with inheritance.

When you rely on inheritance all the way down your class hierarchy you have a massively coupled system, which means it’s difficult, and perhaps impossible to design an external fault-tolerant system by default. I hope it’s no surprise to the reader that software does exist in the real world, and not just in the virtual world. I’m sure that die-hard fans will point to design pattern solutions, but they involve clever use of interfaces and avoid inheritance anyway.
If you rely on inheritance that much, you have misunderstood OOP.

Inheritance strongly implies a hierarchical structure to the software (both the data and the behaviour) Is this a good idea? Look at the extremely successful and mathematically robust relational model. The data structures are mostly acyclic graphs (of which a hierarchy is one.) How do you propose to write a data-mapping layer between an acyclic graph and a hierarchy?
You make it seem as if, say, a File object should derived from the Directory object that contains it, or something like that. I hardly need to point out that OOP doesn't work that way, do I?

For those who don’t know a tree is a restricted form of acyclic graph. Once again we see that OO restricts what can naturally be modelled from the real world, and the relational model (I’m going to start using RM, now because I’m sick of typing ‘relational model’) allows you to model whatever it is that you need.
Absolute nonsense! Object relationships in OOP model a possibly cyclic graph. Object inheritance would be modeled by separating common data of several tuples into a separate tuple referenced by the others. The behaviour doesn't come into play here, because the relational data model has no concept of behaviour.

Don't blame misuse of a paradigm on the paradigm.