3 ms·

"Student is also a Teacher, or becomes Teacher after he graduates" - That's the result of not using composition... "No matter that sometimes people are studyin

by UK-AL 15y ago

"Student is also a Teacher, or becomes Teacher after he graduates" - That's the result of not using composition... "No matter that sometimes people are studying on 2 facoulties" -- Why doesn't this work? Just use a collection, several students inside a collection object... "And when we could use relational DB, it was always with ORM, because objects are needed in any modern system." - Because you manually want to populate objects with tons of boilerplate? Just sounds like results of bad design in general, not OO...

jerf 15y ago
"That's the result of not using composition..." 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.
- UK-AL 15y ago
  "So, embed an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a relational database in OO and its problems go away?" 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?
  - jerf 15y ago
    "When did I ever say that?" 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.
    - UK-AL 15y ago
      Yes of course ORMS use relational systems order the hood, everyone knows that. Relational Databases are easy to use, but that's not the problem. The problem comes from interfaceing the two different systems together. That's the problem. ORMS allow you to remove boilerplate, such manually populating objects, or connection code or whatever and still access relational features. They don't force you to use PURE OO to access data. If you wanted that you'd use a object database... They've existed for years. 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...
    - eli_gottlieb 15y ago
      If you're looking to replace a relational database, then you're looking for orthogonal persistence.
- pradocchia 15y ago
  I've found some places where OO works (the traditional UI widgets still tend to work pretty 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.
  - UK-AL 15y ago
    "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.
- Retric 15y ago
  There is nothing informal about using linq. Y = X.where(p => p.name == "Bob"); PS: You can also use the select syntax if you want.
ajuc 15y ago
> "No matter that sometimes people are studying on 2 facoulties" Why doesn't this work? Just use a collection, several students inside a collection object... 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.
- UK-AL 15y ago
  What? You don't keep the objects permanently in memory. You call up the faculty object via ORM, perform your action such deleting a student. Then get rid of the facaulity object(Going out scope in the method). Next to you call up the faculty object via orm everything's updated. "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...

by UK-AL 15y ago

jerf 15y ago

"That's the result of not using composition..." 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.

UK-AL 15y ago
"So, embed an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a relational database in OO and its problems go away?" 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?
- jerf 15y ago
  "When did I ever say that?" 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.
  - UK-AL 15y ago
    Yes of course ORMS use relational systems order the hood, everyone knows that. Relational Databases are easy to use, but that's not the problem. The problem comes from interfaceing the two different systems together. That's the problem. ORMS allow you to remove boilerplate, such manually populating objects, or connection code or whatever and still access relational features. They don't force you to use PURE OO to access data. If you wanted that you'd use a object database... They've existed for years. 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...
  - eli_gottlieb 15y ago
    If you're looking to replace a relational database, then you're looking for orthogonal persistence.
pradocchia 15y ago
I've found some places where OO works (the traditional UI widgets still tend to work pretty 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.
- UK-AL 15y ago
  "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.
Retric 15y ago
There is nothing informal about using linq. Y = X.where(p => p.name == "Bob"); PS: You can also use the select syntax if you want.

ajuc 15y ago

> "No matter that sometimes people are studying on 2 facoulties" Why doesn't this work? Just use a collection, several students inside a collection object... 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.

UK-AL 15y ago
What? You don't keep the objects permanently in memory. You call up the faculty object via ORM, perform your action such deleting a student. Then get rid of the facaulity object(Going out scope in the method). Next to you call up the faculty object via orm everything's updated. "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...