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: S Perryman on 18 Jan 2008 12:28 topmind wrote: > On Jan 17, 1:00 pm, S Perryman <q...(a)q.com> wrote: TM> but nobody shown a practical example SP>Strange. Because "practical examples" are so easy to define. SP>And a basic example exists in a book you have so often claimed to debunk. SP>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 LOL. As expected, you are unable to present the techniques you espouse in the context of the five issues that I gave. But actually, that is not strictly true. You have certainly shown that your solution *cannot deal* with #2 and #3. Your "table" combinatorially explodes as the cartesian product of types and properties. Every type represented in that table, and the functions associated with the type, are impacted by *every change* to the table. Correspondingly, you have shown that your solution cannot deal with #5. You cannot prevent access to fields in the table for instances of types that do not possess the properties represented by those fields. So in summary, your "solution" : - couples publication types to changes in properties of others. Both *definition* and *implementation* . - cannot provide type correctness Therefore your "solution" does not in fact solve 3 of the 5 major issues relating to the variant record problem. QED. I shudder to think what #1 and #4 actually look like in your world, given the mess you made of #2 / #3 / #5. Regards, Steven Perryman
From: S Perryman on 18 Jan 2008 13:04 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? SP>All of those people who have used it to implement systems at worst SP>as well as preceding paradigms, and at best much better. TM>I've heard a lot of complaints about OO failures also, especially when TM>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. And a lot of the time it is the paradigm itself being used for something it is not best suited for. > Are we comparing bad OO to bad P/R? Are we comparing 'good OO' to 'good 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. Of course, you have *objective* evidence that all of the rhetoric above is anything other than an ignorant, uneducated rant ... > 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. Of course, you have *objective* evidence that all of the rhetoric above is anything other than an ignorant, uneducated rant ... > 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 Is this the "example" that I am on record on comp.object as showing that you in fact did not do a "like for like" implementation of the features that Robert Martin defines in his book ?? > 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 Which all appears to be about a *UI* for a payroll system. Are you claiming that "P/R" builds better UIs than OO ?? >>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. 1. Of course, you have *objective* evidence that all of the rhetoric above is anything other than an ignorant, uneducated rant ... 2. OO does take advantage of set theory, because it is *orthogonal* to set theory. 3. OO does not use *particular implementations* of set theory imposed by certain products, because they conflict with the ADT concept (encapsulation of behaviour + representation) . The desire for an RDB that is compatible with the ADT model (and programming languages thereof) is one that is very strong for experienced OO practitioners. TM>In the past didn't you claim that RDBMS were "too slow", not TM>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. No problem. You have a system that manages telephone lines and the services offered over those lines. You have about 50-100 types of entity representing the various logical/physical resources. Each phone line/service is represented by about 5-6 entity instances. These entities have properties in common, and properties specific to each entity. These properties are grouped into the 100 different entity types, and specific entity types can also be treated as instances of other types (are the alarm bells ringing yet ... ?? ) . Interfacing systems can reference and manipulate entity instances E as instances of *any type* that E is defined to be an instance of. International standards mandate that when instances are created, they become nodes in a tree. There are rules as to which entity types can be parent nodes, and which can be child nodes. The parent/child rules can be defined in terms of specific entity types P/C, or in terms of *any* type that is also deemed to be of type P/C. The system is required to manage *500,000* telephone lines. A system implemented using OO talk all the above in its stride. A system implemented in "procedural/relational" (C, Unix, Oracle) ground itself into a quivering development/performance wreck when actually managing orders of magnitude *less* than the system I worked on. But anyway, feel free to show us how all those "procedural/relational" bods at a big big telco got it all wrong with the means they had to hand. TM>And books etc. don't limit the scope of OO to domains TM>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. <X> authors rarely put scope limitations on <X> claims. Thus, newbies go around sticking <X> 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. Paging Mr Pot : message from Mr Kettle ... Regards, Steven Perryman
From: topmind on 18 Jan 2008 17:11 S Perryman wrote: > topmind wrote: > > > On Jan 17, 1:00 pm, S Perryman <q...(a)q.com> wrote: > > TM> but nobody shown a practical example > > SP>Strange. Because "practical examples" are so easy to define. > SP>And a basic example exists in a book you have so often claimed to debunk. > > SP>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 > > LOL. > > As expected, you are unable to present the techniques you espouse in > the context of the five issues that I gave. > > But actually, that is not strictly true. > > You have certainly shown that your solution *cannot deal* with #2 and #3. > Your "table" combinatorially explodes as the cartesian product of > types and properties. Every type represented in that table, and the > functions associated with the type, are impacted by *every change* to the > table. Please clarify. I don't see a combinatorial explosion. What "function" are you referring to? > > Correspondingly, you have shown that your solution cannot deal with #5. > You cannot prevent access to fields in the table for instances of types > that do not possess the properties represented by those fields. I don't know what you are envisioning here. The end user is normally not going to be given direct access to the tables. > > So in summary, your "solution" : > > - couples publication types to changes in properties of others. Both > *definition* and *implementation* . Please clarify. > > - cannot provide type correctness Validation can be added anywhere one pleases. If we want to put it in DB triggers so that ALL inserts and updates are checked so that no Foo can have a Bar if so deemed, we can. So far, that seems overkill for this kind of app. The screen won't ask for fields that don't belong to a given category/type of publication. (We may need to prompt them if they change the category and there items that don't belong.) And I am curious to see how your OO solution allows administrative users to add publication categories. Or, do they have to call your consultancy for $120 per hour? Brilliant from a con/salesmen standpoint, but not economical for the customer. > > > Therefore your "solution" does not in fact solve 3 of the 5 major issues > relating to the variant record problem. > > QED. FUD in Perryland. > > > I shudder to think what #1 and #4 actually look like in your world, given > the mess you made of #2 / #3 / #5. > > > Regards, > Steven Perryman -T-
From: topmind on 18 Jan 2008 17:33 On Jan 18, 10:04 am, S Perryman <q...(a)q.com> 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? > > SP>All of those people who have used it to implement systems at worst > SP>as well as preceding paradigms, and at best much better. > > TM>I've heard a lot of complaints about OO failures also, especially when > TM>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. > > And a lot of the time it is the paradigm itself being used for something > it is not best suited for. Unicorns unicorns unicorns. > > > Are we comparing bad OO to bad P/R? > > Are we comparing 'good OO' to 'good 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. > > Of course, you have *objective* evidence that all of the rhetoric above > is anything other than an ignorant, uneducated rant ... No, that is a personal observation/anecdote. If only objective facts were allowed on comp.object, then there would only be like one post a month. At least I know when my observations or opinions are not objective info. > > > 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. > > Of course, you have *objective* evidence that all of the rhetoric above > is anything other than an ignorant, uneducated rant ... > > > 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 > > Is this the "example" that I am on record on comp.object as showing that > you in fact did not do a "like for like" implementation of the features > that Robert Martin defines in his book ?? Is there something missing you wish to go over, or are you just looking for a nit to pick? Note that I left a few items out because I fealt they were mostly site- specific features that could be implimented by using and updating the info in the given tables. > > > 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 > > Which all appears to be about a *UI* for a payroll system. > Are you claiming that "P/R" builds better UIs than OO ?? I wouldn't classify it about being mostly UI related. In fact, my implementation didn't include any UIs other than stub output. > > >>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. > > 1. Of course, you have *objective* evidence that all of the rhetoric above > is anything other than an ignorant, uneducated rant ... See above. > > 2. OO does take advantage of set theory, because it is *orthogonal* to > set theory. Bull. If you use giant navigational object pointer structures, you are NOT using direct sets. Using both is likely unnecessary duplication. > > 3. OO does not use *particular implementations* of set theory imposed by > certain products, because they conflict with the ADT concept (encapsulation > of behaviour + representation) . The desire for an RDB that is compatible > with the ADT model (and programming languages thereof) is one that is very > strong for experienced OO practitioners. ADT's are not always the right tool. > > TM>In the past didn't you claim that RDBMS were "too slow", not > TM>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. > > No problem. > > You have a system that manages telephone lines and the services offered > over those lines. You have about 50-100 types of entity representing the > various logical/physical resources. > > Each phone line/service is represented by about 5-6 entity instances. > These entities have properties in common, and properties specific to each > entity. These properties are grouped into the 100 different entity types, > and specific entity types can also be treated as instances of other types > (are the alarm bells ringing yet ... ?? ) . > > Interfacing systems can reference and manipulate entity instances E as > instances of *any type* that E is defined to be an instance of. > > International standards mandate that when instances are created, they > become nodes in a tree. There are rules as to which entity types can be > parent nodes, and which can be child nodes. The parent/child rules can be > defined in terms of specific entity types P/C, or in terms of *any* type > that is also deemed to be of type P/C. > > The system is required to manage *500,000* telephone lines. > > A system implemented using OO talk all the above in its stride. > > A system implemented in "procedural/relational" (C, Unix, Oracle) ground > itself into a quivering development/performance wreck when actually > managing orders of magnitude *less* than the system I worked on. > > But anyway, feel free to show us how all those "procedural/relational" > bods at a big big telco got it all wrong with the means they had to hand. If you don't mind, I'd like to see some sample data. It may help clarify some of the domain lingo. And I repeat, most non-trivial biz apps cannot effectively use hierarchical subtyping. It WILL become a mess, especially if we want administrative users to manage classification systems instead of programmers. Here's something I wrote for the C2.com wiki: I find in business applications that its important and useful to think of variations-on-a-theme as modeling a buffet restaurant: pick and choose the features (items) that you want. Generally one wants to separate the implementation of features from the encoding of them (data). Paradigms or techniques that try to closely associate the implementation with the feature encoding itself generally have scalability or maintainability problems. Differing ways to encode them include: Tables with Boolean switches or indicators. Here's an example Product table: table: Products --------------- productID description feature_A // Boolean feature_B // Boolean feature_C // Boolean feature_etc... (Note: in practice columns would have a more descriptive names. "Feature" is merely a stand-in.) Many-to-Many feature tables: table: Features ------------ featureID description table: Product_Features ------------ productRef // foreign key to productID in Products featureRef // foreign key to featureID in Features Associative arrays or object attributes: p = newArray(); p["feature_b"] = true; p["feature_f"] = true; // non-mentioned features are assumed false (or per-feature default) Named parameters (KeywordParameterPassing) in function or method calls: doSomething(productID, feature_B=true, feature_F=true); // non-selected features are off or have defaults, based on convention If not supported, I sometimes emulate KeywordParameters? with descriptive flags inside of parenthesis: doSomething(productID, "(feature_b)(feature_f)(feature_w)"); The parenthesis approach is easy to parse in many languages, including SQL. See also EmulateKeywordAndDefaultParameters. Keep in mind that features are not necessarily Boolean. For example, text alignment may be "left", "center", or "right". These are trickier to emulate with the parenthesis approch, but one can use indicators such as "(align_left)". (end quote) > > Regards, > Steven Perryman -T-
From: frebe on 19 Jan 2008 01:43
> 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. create table vehicle ( vehicleid integer, name string, primary key (vehicleid) ) create table car ( vehicleid integer, engine_volume double, primary key (vehicleid), foreign key (vehicleid) references vehicle (vehicleid) ) careate table boat ( vehicleid integer, propellercount smallint, primary key (vehicleid), foreign key (vehicleid) references vehicle (vehicleid) ) > 2. changing the properties of any member of the > set, without affecting/impacting the other members (interface, impl) . update vehicle set name='Boat' + name where vehicleid in (select vehicleid from boat) > 3. changing the representations (impls) of any member of the > set, without affecting/impacting the other members (interface, impl) . alter table boat modify propellercount integer > 4. changing the code written by users of the entity set, whenever the > members of the set changes. Function pointers > 5. correctness (being able to confirm the attempted use of properties > that do or do not belong to members of the set) . update car set propellercount=5 where vehicleid=3 will case an error //frebe |