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.