Historically, OO's acceptance of composition over inheritance only came after a decade of experience that showed inheritance doesn't work as promised. (Or two decades, depending on your accounting.) Composition as an answer came later.

"Just use a collection, several students inside a collection object..."

So, embed an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a relational database in OO and its problems go away?

I've found some places where OO works (the traditional UI widgets still tend to work pretty well), but it isn't even close to a panacea and if you compare the initial promises to what it can actually deliver, history has not treated it that well.

And that's where OO initially gained traction. At the time, UI was a major pain. OO was a good fit. UI elements have state, and can do things. Bundling them together made a lot of sense. Inheritance also worked well, as all the objects were purely artificial creations. They were precisely how one chose to define them in code.

Problem was, the rest of the world is not like UI widgets. The main difference being, it has a reality external to the code. State and behavior are not so obviously bundled into types and instances. Verbs are sometimes more important the nouns.

But OO had been sooo successful w/ UI widgets, that many people hoped to repeat that success more widely. OO also provided an easy way to dumb things down--"everything is an object" obscures all the hard questions--just start with objects, and keep writing code until the thing works.

That's a silly argument. It could be applied to almost any programming language. Just start with functions...

The hard choices are what data structures, and algorithms to use and OO does not get rid of that.

When did I ever say that?

If you wanted to search the database, say people with a certain name, belonging to certain faculty, you'd have a separate method that indirectly runs SQL statement or ORM statement for you.... Perhaps belonging to the faculty object, the method taking the name as the param.

You could even have a single generic search method belonging to the faculty object, that allows a whole range of relational features(SETs etc) to be used in the search.

If you wanted to search all students, you'd have a generic search method, on the student object?

That's the most obvious design ever? Unless you wanted to make it difficult?

You answered the question as if that really was the only many-to-many relationship in the system. I observe that it is only an exemplar, and that in practice any real system is shot through with similar relationships, and the answer isn't to implement each one of them in OO.

If you're using an ORM, btw, you're using a relational system under the hood, which is my point. You seemed to be implying pure OO had answers to that problem, and it really doesn't unless it imports a foreign paradigm like a relational database. If that wasn't your intent, then we're in agreement.

ORMS allow you to use those relational features(HQL, LINQ), except without the boilerplate of manually populating objects, connecting to the database or whatever...

Nearly every search you perform via orm, uses relational operations...

Y = X.where(p => p.name == "Bob");

PS: You can also use the select syntax if you want.

Student <-> Facoulty is many to many relation. I can make Faculties keeping arrays of pointers to Students, and Students keeping arrays of pointers to facoulties, and update both arrays accordingly when something changes.

Then I want to save the information, that Student X finished Facoulty Y, but still studies at Facoulty Z.

So pointers from student to facoulties won't suffice. I need to have a place to keep this data. So I introduce Relation object, like I should have from the start. And I end the Student/Teacher maddness, and make Person<-Relation->Facoulty. Much better.

Then I want to be able to filter students according to different conditions. And I end up writing nested loops for every possible condition and join I need. I refactor. I generalize. After a few months or years I've implemented nonstandard relational database.

> Because you manually want to populate objects with tons of boilerplate?

Because I don't want to have objects at all, when relational db is the right tool.

"Then I want to be able to filter students according to different conditions. And I end up writing nested loops for every possible condition and join I need. I refactor. I generalize. After a few months or years I've implemented nonstandard relational database."

Only a moron would write loops to search using an ORM. You implement a generic search method on the object, which executes the relevant SQL statement(Via HQL or LINQ) and returns the result. ORMS do this stuff automatically, no need to write loops to search...

I mean how badly have you been abusing ORMS?

You've been using ORMS wrong. ORMS provide the whole range relational features. They just map the results of the SQL statement into objects.

Relational Databases are good keeping data integrity correct, not so good at modelling computations. So you use the best tool for the job, relational database for storing data. Then extract that data from the database, and then use whatever (functional, OO, logic languages) to perform operations on that data.

Relational is not a way to perform computations on data, other than searching and using the various relational search features. Try implementing a machine learning algo on data using solely SQL...

I described how I've been taught OO. First without using databases, and with wrong abstractions (nouns instead of relations, when the system was all about relations). I think it's the default experience, because I've seen many such examples of bad OO design.

Then we've been taught databases, but using ORMs, like it was the only possible way, because objects are required for the system to be modern. And I don't like that too, because IMHO (OO + ORM + relational DB) doesn't add any value over (procedural programming with relational DB), but adds complexity, and is less transparent.

If you prefer procedural code, then obviously ORMs are no use to you...

I mean love various programming paradigms, I like Haskell, but it can make things difficult. For example programming a basic game in haskell, is far from simple. You normally have to introduce reactive programming to make it sane.

I find OO makes large systems easier.

In my opinion the amount of boilerplate required for JDBC makes ORM a must in java...