Why is Object Oriented so successfull
in [OOP]
|
Prev: Proxy pattern: remote chat proxy and interfaces
Next: Derived class calling overriden base class methods
From: topmind on 17 Jan 2008 14:48 S Perryman wrote: > topmind wrote: > > > alexcpn wrote: > > >>Now a sudden thought stuck me. What if sometime in the future somebody > >>armed with concrete statistics come and tell me that OO is too > >>complicated and that most of the key words which we swear by like > >>inheritance, polymorphisms etc really do not provide much value to the > >>vast millions of OO code out there; I really believe part of this > >>since I know a little about the code in one of the largest OO code > >>base in the telecom network management product that I work in. > > >>Maybe I should frame the question more clearly- what is it so special > >>in OO that makes it so successfully industrially. I really don't > >>'believe' that it is because of the way OO entity help us in closely > >>modeling real life etc > > > Who says its successful? > > All of those people who have used it to implement systems at worst > as well as preceding paradigms, and at best much better. I've heard a lot of complaints about OO failures also, especially when they don't have to go on official record. > > > > Its one of those things that people pay lip- > > service to because they have been brainwashed into believing it is > > better for you, as if it was broccoli; yet there is no SCIENTIFIC > > EVIDENCE that OOP is better. NONE (at least for biz apps). > > > I've challenged OO fans to prove it objectively better for custom biz > > apps for over a decade, and they CANNOT show it with source code. It > > always turns into my personal preference versus theirs, not some clear- > > cut quantity. I don't dispute that OO may model *some* people's brains > > better than others, but every brain is different. > > No. It "turns out" that the problems that your mythical "biz apps" have > to solve have no real need for OOP beyond the approaches you espouse. > > Nothing wrong with that. > > However, for many of the types of problem that others face (telecoms etc) , > the approaches you espouse have been shown to be badly wanting (note to > the reader : topmind does not like to discuss them because they are not > his mythical "biz apps" and he knows his flawed claims immediately die a > horrible death) . > Perhaps. In the past didn't you claim that RDBMS were "too slow", not that they were the wrong paradigm from organizational perspective? Note that I worked on big telecom billing and marketing apps, and they didn't use a lot of OOP And books etc. don't limit the scope of OO to domains, implying everywhere is fine. > > > The biggest fault of OO is that it does NOT take the lessons of > > collection-oriented programming and set theory. It degenerates into a > > mess of pointers, the GO TO of the new era. > > OO is orthogonal to "collection-oriented" programming and set theory. > And is easily capable of dealing with, and operating in, environments in > which collections/sets of entities are required. > > > Regards, > Steven Perryman
From: rugby fan on 17 Jan 2008 15:37 topmind wrote: > S Perryman wrote: A>Maybe I should frame the question more clearly- what is it so special A>in OO that makes it so successfully industrially. I really don't A>'believe' that it is because of the way OO entity help us in closely A>modeling real life etc TM>Who says its successful? >>All of those people who have used it to implement systems at worst >>as well as preceding paradigms, and at best much better. > I've heard a lot of complaints about OO failures also, especially when > they don't have to go on official record. I've experienced a lot of complaints about "procedural/relational" failures too. Some I have been first-hand witness to. As with any method/process/paradigm, I am interested in why one succeeds and one fails. Are you ?? TM>I've challenged OO fans to prove it objectively better for custom biz TM>apps for over a decade, and they CANNOT show it with source code. It TM>always turns into my personal preference versus theirs, not some clear- TM>cut quantity. I don't dispute that OO may model *some* people's brains TM>better than others, but every brain is different. >>No. It "turns out" that the problems that your mythical "biz apps" have >>to solve have no real need for OOP beyond the approaches you espouse. >>Nothing wrong with that. >>However, for many of the types of problem that others face (telecoms etc) , >>the approaches you espouse have been shown to be badly wanting (note to >>the reader : topmind does not like to discuss them because they are not >>his mythical "biz apps" and he knows his flawed claims immediately die a >>horrible death) . > Perhaps. In the past didn't you claim that RDBMS were "too slow", not > that they were the wrong paradigm from organizational perspective? I have worked on telecoms systems where RDBMS have been used, and have failed. Both times was that it was just the wrong paradigm. The first didn't ostensibly affect performance, although development was tedious and painful. The second certainly did, and was a big joke for a big telecoms company. > Note that I worked on big telecom billing and marketing apps, and they > didn't use a lot of OOP Billing systems (traditionally - not so much now due to the rise of the rating process etc) don't really need OO. > And books etc. don't limit the scope of OO to domains A "domain" is a subject domain, something of fact/interest for which people wish to build systems to provide some useful purpose for that domain. > implying everywhere is fine. A completely meaningless statement. [ my reply to you on OO and "lessons" - and your non-answer thereof - is duly noted as revealing fallacy on your part. ] Regards, Steven Perryman
From: S Perryman on 17 Jan 2008 16:00 topmind wrote: > S Perryman wrote: TM>What "variant record problem"? TM>I've asked for this in the past >>The "issue" of : >>1. having a set of related entities, all/some having the same >>properties, and each having properties specific to itself. Users of >>the entities may wish to reference instances of the set as an entity >>that has properties in common, or as the specific entity type. >>2. changing the properties of any member of the >>set, without affecting/impacting the other members (interface, impl) . >>3. changing the representations (impls) of any member of the >>set, without affecting/impacting the other members (interface, impl) . >>4. changing the code written by users of the entity set, whenever the >>members of the set changes. >>5. correctness (being able to confirm the attempted use of properties >> that do or do not belong to members of the set) . >>All of these issues are known to experienced developers having faced >>the variant record problem. >>Similarly, said developers know that various programming paradigms/ >>langs can solve some of the problems, but not all. Type substitutability >>(when used with other constructs/techniques) allows all of them to be >>resolved. TM> but nobody shown a practical example >>Strange. Because "practical examples" are so easy to define. >>And a basic example exists in a book you have so often claimed to debunk. > Then it should be easy for you to bring one up without fuss or muss. Object Oriented Software Construction 2. Page 62. The PUBLICATION type. Note for readers : the example is about publications (books, journals etc) that have properties in common (author etc) and properties specific to each. Publications that would be used in a library system (biblio search etc) . Feel free to show us how "procedural/relational" addresses the problems of 1-5 that I have already listed. If you can do the following : - explain the mechanism needed to address the problem - give citations to *existing* prog langs that support the mechanism that would be much appreciated by readers IMHO. So, in your own time ... Regards, Steven Perryman
From: topmind on 18 Jan 2008 11:41 On Jan 17, 1:00 pm, S Perryman <q...(a)q.com> wrote: > topmind wrote: > > S Perryman wrote: > > TM>What "variant record problem"? > > TM>I've asked for this in the past > > > > > > >>The "issue" of : > >>1. having a set of related entities, all/some having the same > >>properties, and each having properties specific to itself. Users of > >>the entities may wish to reference instances of the set as an entity > >>that has properties in common, or as the specific entity type. > >>2. changing the properties of any member of the > >>set, without affecting/impacting the other members (interface, impl) . > >>3. changing the representations (impls) of any member of the > >>set, without affecting/impacting the other members (interface, impl) . > >>4. changing the code written by users of the entity set, whenever the > >>members of the set changes. > >>5. correctness (being able to confirm the attempted use of properties > >> that do or do not belong to members of the set) . > >>All of these issues are known to experienced developers having faced > >>the variant record problem. > >>Similarly, said developers know that various programming paradigms/ > >>langs can solve some of the problems, but not all. Type substitutability > >>(when used with other constructs/techniques) allows all of them to be > >>resolved. > > TM> but nobody shown a practical example > > >>Strange. Because "practical examples" are so easy to define. > >>And a basic example exists in a book you have so often claimed to debunk.. > > Then it should be easy for you to bring one up without fuss or muss. > > Object Oriented Software Construction 2. Page 62. The PUBLICATION type. > Note for readers : the example is about publications (books, journals etc) > that have properties in common (author etc) and properties specific to > each. Publications that would be used in a library system (biblio search > etc) . I happened to discuss that very example as part of my OOSC2 critique several years ago: http://www.geocities.com/tablizer/lib.htm I generally proposed a "feature table" instead of hierarchies (which wouldn't surprise those familiar with my modeling philosophy). The traditional OO solution of subtyping is not sufficient enough and not as powerful as feature sets. Just about ANY non-trivial classification system will grow to be non-tree over time. Trees are limiting (unless one duplicates leaves, which is bad modelling if done often). Some OO fans may even recommend dynamic composition (HAS-A)instead of subtyping (but then they are reinventing an ugly navigational database which are the Go To equiv of structures). Plus, some fuss over "wasting columns" that are not used for a parrticular instance. Modern RDBMS do not used fixed column widths internally and thus unused fields take very little or no bytes, depending on the implimentation. Your complaints are too tree-based and based on 70's database technology. Get with the times and get with Set Theory. Excerpts: My business software experience tells me that anything dealing with variations (subtypes) MUST be flexible. In this example, new mediums (variations) were being added as I watched: They had videos, CD's, and even training software in their library. What new media and publication types will there be in the future? What about hybrids? What about a book that also contains a CD or video? [common for tech books] The mutually exclusiveness of traditional OO types is now a poor model for our "has X and Y". Suppose videos were added as a publication type. "Length" (duration) is proposed as one of the new fields pertaining to videos. After several months go by, someone points out that Length can pertain to other publication types. For example, almost anything with paper can have "number of pages". Software can even have it's size in "K" or "megs" as it's length. (One might also want to think about having a "Unit_of_Measure" field to make it more open ended. Unit-of-Measure could be pages, minutes, megabytes, etc. The unit-of-measure could be tied to the item type so that it does not have to be retyped for every entry.) In the OO tree approach, first the programmer will add Length to the Video subtype. Then when it is later agreed to have Length apply to other types as well, the programmer has to come back in and move the field Length back to the root class (Publications). In the feature- list approach, the "Field Administrator" only has to open up the type control table and make a few simple mouse or keyboard clicks. It is in essence, "subtype painting by number." (The "Field Administrator" may or may not be a programmer.) It is often not practical to expect a programmer to come tromping in every time a new variation is added or changed. That can be expensive, especially if a new (turnover) programmer has to reverse-engineer the existing code, which they will not be familiar with. The feature-list approach is much more flexible. It is often also safer because one does not have to meddle in the code to add or change variations. (end quote) > > Feel free to show us how "procedural/relational" addresses the problems of > 1-5 that I have already listed. If you can do the following : > > - explain the mechanism needed to address the problem > - give citations to *existing* prog langs that support the mechanism They are called "relational tables". I suggest you read up on them. > > that would be much appreciated by readers IMHO. > > So, in your own time ... > > Regards, > Steven Perryman- Hide quoted text - > > - Show quoted text - -T-
From: topmind on 18 Jan 2008 12:05
rugby fan wrote: > topmind wrote: > > > S Perryman wrote: > > A>Maybe I should frame the question more clearly- what is it so special > A>in OO that makes it so successfully industrially. I really don't > A>'believe' that it is because of the way OO entity help us in closely > A>modeling real life etc > > TM>Who says its successful? > > >>All of those people who have used it to implement systems at worst > >>as well as preceding paradigms, and at best much better. > > > I've heard a lot of complaints about OO failures also, especially when > > they don't have to go on official record. > > I've experienced a lot of complaints about "procedural/relational" > failures too. Some I have been first-hand witness to. A lot of the times it is just bad programming/design, or limiting tools. For example, Oracle is kind of stiff and bulky for projects that need to be nimble. That is not the fault of relational in general, but a misapplied vendor's product. Are we comparing bad OO to bad P/R? I'd take bad P/R over bad OO because bad P/R tends to be more predictable in where it goes wrong. Bad OO can be very messy because somebody may inject some screwy philosophical underpinnings into their design. OO tends to attract methodology fad zealots, while P/R less so. If you want to create and compare a sample app to show OO being good, how about using Robert Martin's payroll example: http://www.geocities.com/tablizer/payroll2.htm An approximate version of what's in Robert Martin's OO code from the book can be found here: http://www.codeproject.com/KB/books/PatternsPractices.aspx > > As with any method/process/paradigm, I am interested in why one succeeds > and one fails. Are you ?? > Indeed. In my opinion, OO tends to fail or bog down because it does not take advantage of Set Theory and the inspectability of tables over code. Code is just harder to read, search, and sift for many or most than the equivalent in a DB. Plus, power-users can update product classification tables (via screens) easier and cheaper than programmers changing OO subclasses. OO is job security for programmers, turning them into overpayed classification clerks, but not a lot of efficiency. > > TM>I've challenged OO fans to prove it objectively better for custom biz > TM>apps for over a decade, and they CANNOT show it with source code. It > TM>always turns into my personal preference versus theirs, not some clear- > TM>cut quantity. I don't dispute that OO may model *some* people's brains > TM>better than others, but every brain is different. > > >>No. It "turns out" that the problems that your mythical "biz apps" have > >>to solve have no real need for OOP beyond the approaches you espouse. > > >>Nothing wrong with that. > > >>However, for many of the types of problem that others face (telecoms etc) , > >>the approaches you espouse have been shown to be badly wanting (note to > >>the reader : topmind does not like to discuss them because they are not > >>his mythical "biz apps" and he knows his flawed claims immediately die a > >>horrible death) . > > > Perhaps. In the past didn't you claim that RDBMS were "too slow", not > > that they were the wrong paradigm from organizational perspective? > > I have worked on telecoms systems where RDBMS have been used, and have > failed. Both times was that it was just the wrong paradigm. > > The first didn't ostensibly affect performance, although development > was tedious and painful. > > The second certainly did, and was a big joke for a big telecoms company. > Write up a paper about how relational cannot handle such and such. Us relational fans would like to study the problem in detail. Just because your company couldn't pull it off does not mean it cannot be done. Perhaps you are just not experienced enough with it. > > > Note that I worked on big telecom billing and marketing apps, and they > > didn't use a lot of OOP > > Billing systems (traditionally - not so much now due to the rise of the > rating process etc) don't really need OO. > > > > And books etc. don't limit the scope of OO to domains > > A "domain" is a subject domain, something of fact/interest for which > people wish to build systems to provide some useful purpose for that > domain. > > > > implying everywhere is fine. > > A completely meaningless statement. OO authors rarely put scope limitations on OO claims. Thus, newbies go around sticking OO into everything and their dogs, making messes. > > > [ my reply to you on OO and "lessons" - and your non-answer thereof - > is duly noted as revealing fallacy on your part. ] Perryland reality. Kiss Goofy while you are there. > > > Regards, > Steven Perryman -T- |