Real World Flunks (Re: Why is Object Oriented so successful)
in [OOP]
|
Prev: Call for Papers: The 2008 International Conference of Parallel and Distributed Computing (ICPDC 2008)
Next: Excellent Consultants Available for Different Position
From: topmind on 28 Jan 2008 23:08 AndyW wrote: > On Thu, 24 Jan 2008 21:26:24 -0800 (PST), topmind > <topmind(a)technologist.com> wrote: > > > > > > >AndyW wrote: > >> On Sat, 12 Jan 2008 17:55:50 -0800 (PST), topmind > >> <topmind(a)technologist.com> wrote: > >> > >> > > >> > > >> >Daniel T. wrote: > >> >> alexcpn <alexcpn(a)gmail.com> wrote: > >> >> > >> >> > 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 > >> >> > >> >> Here I must disagree. I think OO does help us to more closely model the > >> >> real world. > >> > > >> >Note that a good many OO proponents disagree that OO is mostly about > >> >"modeling the real world". Bertrand Meyer, for example, dismisses the > >> >idea that modeling the real world is the key point of OO. Further, the > >> >real world sometimes is not the ideal approach. We wouldn't want to > >> >model a physical card catalog in a library, for example. We have > >> >technology that transcends 3D card cabinets. Why be stuck in the 3D > >> >world when a virtual world (indexing) can have gazillion dimensions? > >> > >> There are actually many different philosophies on how to approach OO. > >> For example, I am what is called a purist, so I believe that an > >> object has to be a tangible [real world] thing, with services and > >> mixins used to deal with rule violations. Others think that if > >> something has a name, its an object, yet others have even more > >> esoteric rules. > > > >The problem is that the real world is limiting. With computers we can > >transcend limits of the real world to a fair extent; and if you don't > >take advantage of this, you lose some of the power and flexibility > >that computers can provide, putting your client at a disadvantage. > > > >Take for example car parts. Now, a CADD system may find it very useful > >and efficient to treat the parts as hierarchical sub-assemblies, or at > >least object pointers to each other that reflect their touching in the > >real world (inside the car). Skimming around among the parts on the > >CADD screen closely matches the object pointers in a typical real- > >world-based OO model. > > > >However, materials experts, inventory experts, vendor/supplier > >experts, safety experts, and accountants are also interested in the > >very same parts. However, their interest does not generally reflect > >the part's place in the car. Their categories and groupings and > >classifications are all different. We need something more powerful > >than a bunch of pointers that reflect real-world touching. We need a > >"relative perspective engine", and OO is not that because it would > >become a huge pasta bowl of pointers if we try to scale the same > >technique that worked for CADD to all these different users. > > > >And if you factor it right, "behavior" becomes a secondary issue and > >thus "behavioral wrappers" that OO likes are less useful and > >meaningful. The real "meat" of the system is in its attributes and > >meta-data, NOT behavior per se. > > > >> > >> ---------------- > >> AndyW, > >> Mercenary Software Developer > > > >-T- > > If you have an object (real world) then you can search on the > attributes of that object. No-one cares of the search is represented > to the user. If you are manipulating visual representations or > trawling lists of attributes it makes no difference, at the end of the > day your still dealing with objects. > > If you find yourself searching on metadata, then your not dealing with > objects or a real world thing. > > Basically, if its abstract, then its not an object is it. I'm not sure what your point is. From a developer's perspective, navigational queries for multiple departments are usually harder to compose and maintain than relational equivalents. In OOP it is not easy to maintain all the necessary links/classifications to provide all the mentioned perspectives. Encapsulation does not encapsulate complex links BETWEEN "objects" very well. OOP is lousy at link management when links grow beyond the trivial. "Linkness" is a bottleneck in these kinds of apps if not done right, thus we choose a tool that better handles masses of links/ relationships/categories. Trying to mirror a real world feel for INDIVIDUAL given widgets is the least of our problems here. > > ---------------- > AndyW, > Mercenary Software Developer -T-
From: topmind on 28 Jan 2008 23:14 AndyW wrote: > On Fri, 25 Jan 2008 17:21:00 -0800 (PST), topmind > <topmind(a)technologist.com> wrote: > > > > > > >Dmitry A. Kazakov wrote: > >> On Thu, 24 Jan 2008 21:26:24 -0800 (PST), topmind wrote: > >> > >> > The problem is that the real world is limiting. With computers we can > >> > transcend limits of the real world to a fair extent; > >> > >> Computers are a part of the real world. They cannot transcend the limits of > >> themselves. > > > >Perhaps I didn't word it quite correct. A computer model of the world > >(or part of it) can do things that the real-world counter-part cannot. > >In a video game you can jump 80 feet and live. In real life you > >cannot. Or compare a library (paper) card catalog to Google-like book > >search engines used in libraries now. Only a big dummy would recreate > >the card catalog in a computer as is. > > It seems to me from reading the above that you may be trying to > classify everything as an object (there is a camp of people that do > this) and then saying - hey, not everything fits into that model > ideally. > > From my view, not everything is an object and there are special rules > that state what is and what isnt. There are also special rules for > dealing with the stuff that isnt, such as the use of services and > mixins (functions/procedures and data). Until these "special rules" are documented and studied and analyzed, we cannot rely on them. And, it sounds like it gets further from the "real world". A "mixin" is not readily a real world thing. > > ---------------- > AndyW, > Mercenary Software Developer -T-
From: AndyW on 29 Jan 2008 02:05 On Mon, 28 Jan 2008 20:14:02 -0800 (PST), topmind <topmind(a)technologist.com> wrote: > > >AndyW wrote: >> On Fri, 25 Jan 2008 17:21:00 -0800 (PST), topmind >> <topmind(a)technologist.com> wrote: >> >> > >> > >> >Dmitry A. Kazakov wrote: >> >> On Thu, 24 Jan 2008 21:26:24 -0800 (PST), topmind wrote: >> >> >> >> > The problem is that the real world is limiting. With computers we can >> >> > transcend limits of the real world to a fair extent; >> >> >> >> Computers are a part of the real world. They cannot transcend the limits of >> >> themselves. >> > >> >Perhaps I didn't word it quite correct. A computer model of the world >> >(or part of it) can do things that the real-world counter-part cannot. >> >In a video game you can jump 80 feet and live. In real life you >> >cannot. Or compare a library (paper) card catalog to Google-like book >> >search engines used in libraries now. Only a big dummy would recreate >> >the card catalog in a computer as is. >> >> It seems to me from reading the above that you may be trying to >> classify everything as an object (there is a camp of people that do >> this) and then saying - hey, not everything fits into that model >> ideally. >> >> From my view, not everything is an object and there are special rules >> that state what is and what isnt. There are also special rules for >> dealing with the stuff that isnt, such as the use of services and >> mixins (functions/procedures and data). > >Until these "special rules" are documented and studied and analyzed, >we cannot rely on them. And, it sounds like it gets further from the >"real world". A "mixin" is not readily a real world thing. They are well documented, a mixin in say a language such as C/C++ is otherwise known as a struct. In comparison to a class, a mixin has no methods. A class with methods but no data is a service (basically a group of related functions). These are old procedural techniques. The OO stuff just builds on that. ---------------- AndyW, Mercenary Software Developer
From: AndyW on 29 Jan 2008 03:08 On Mon, 28 Jan 2008 20:08:15 -0800 (PST), topmind <topmind(a)technologist.com> wrote: > > >AndyW wrote: >> On Thu, 24 Jan 2008 21:26:24 -0800 (PST), topmind >> <topmind(a)technologist.com> wrote: >> >> > >> > >> >AndyW wrote: >> >> On Sat, 12 Jan 2008 17:55:50 -0800 (PST), topmind >> >> <topmind(a)technologist.com> wrote: >> >> >> >> > >> >> > >> >> >Daniel T. wrote: >> >> >> alexcpn <alexcpn(a)gmail.com> wrote: >> >> >> >> >> >> > 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 >> >> >> >> >> >> Here I must disagree. I think OO does help us to more closely model the >> >> >> real world. >> >> > >> >> >Note that a good many OO proponents disagree that OO is mostly about >> >> >"modeling the real world". Bertrand Meyer, for example, dismisses the >> >> >idea that modeling the real world is the key point of OO. Further, the >> >> >real world sometimes is not the ideal approach. We wouldn't want to >> >> >model a physical card catalog in a library, for example. We have >> >> >technology that transcends 3D card cabinets. Why be stuck in the 3D >> >> >world when a virtual world (indexing) can have gazillion dimensions? >> >> >> >> There are actually many different philosophies on how to approach OO. >> >> For example, I am what is called a purist, so I believe that an >> >> object has to be a tangible [real world] thing, with services and >> >> mixins used to deal with rule violations. Others think that if >> >> something has a name, its an object, yet others have even more >> >> esoteric rules. >> > >> >The problem is that the real world is limiting. With computers we can >> >transcend limits of the real world to a fair extent; and if you don't >> >take advantage of this, you lose some of the power and flexibility >> >that computers can provide, putting your client at a disadvantage. >> > >> >Take for example car parts. Now, a CADD system may find it very useful >> >and efficient to treat the parts as hierarchical sub-assemblies, or at >> >least object pointers to each other that reflect their touching in the >> >real world (inside the car). Skimming around among the parts on the >> >CADD screen closely matches the object pointers in a typical real- >> >world-based OO model. >> > >> >However, materials experts, inventory experts, vendor/supplier >> >experts, safety experts, and accountants are also interested in the >> >very same parts. However, their interest does not generally reflect >> >the part's place in the car. Their categories and groupings and >> >classifications are all different. We need something more powerful >> >than a bunch of pointers that reflect real-world touching. We need a >> >"relative perspective engine", and OO is not that because it would >> >become a huge pasta bowl of pointers if we try to scale the same >> >technique that worked for CADD to all these different users. >> > >> >And if you factor it right, "behavior" becomes a secondary issue and >> >thus "behavioral wrappers" that OO likes are less useful and >> >meaningful. The real "meat" of the system is in its attributes and >> >meta-data, NOT behavior per se. >> > >> >> >> >> ---------------- >> >> AndyW, >> >> Mercenary Software Developer >> > >> >-T- >> >> If you have an object (real world) then you can search on the >> attributes of that object. No-one cares of the search is represented >> to the user. If you are manipulating visual representations or >> trawling lists of attributes it makes no difference, at the end of the >> day your still dealing with objects. >> >> If you find yourself searching on metadata, then your not dealing with >> objects or a real world thing. >> >> Basically, if its abstract, then its not an object is it. > >I'm not sure what your point is. From a developer's perspective, >navigational queries for multiple departments are usually harder to >compose and maintain than relational equivalents. [as an aside - I have found that for me, this is not true - but it could be for others] >In OOP it is not >easy to maintain all the necessary links/classifications to provide What link/classifications ? Is this something one has in the relational world. To me associations between two objects are usually abstract. The principle rule I use here is that an object does not 'know' about other objects (this is why they often communicate using an event model of some kind) As an example I would suggest that if one thinks about it one would be hard to discover a relationship or link between a cup and the liquid coffee, other than an abstraction humans apply. No cup has any 'knowledge' of liquid and no liquid has any knowlede of cups (as far as I am aware - I have never been able to get any tangible answer from cups I have asked this question to). The relationship to me is abstract [metadata] and applicable from the human perspective and therefore likely to be (but not always) modelled in the business logic rather than the schema. This I think is not to be confused with composite objects which in some cases may be abstractions or may be concrete (this is the application to that invoice/payment example posted previously). With a composite object, I think the fact one has a reference to it means one already have a reference to its parts as well. Given this, why transverse the object to find a part when one can use the rule that objects know how to perform actions on themselves (but not others), so one simply asks the object to perform the action on its parts (in the invoice/payment example) In the invoice example, having a reference to the invoice means the payments are known as well (its the same object). In that respect methods performActionOnInvoice and performActionOnPayment are both in scope at the same instance of time (this is what encapsulation means) there is no need to traverse any structure to look for the sub-parts. To me if the object is non-transient, that is it exists in persistant storage (the object lives longer than the application that created it) there is no access mechanism or database lookup. If one knows the object it can be referenced directly, if one doesnt, one posts the appropriate request (event) and the appropriate objects respond (listener design pattern for example) by either making themselves known, or by performing the requested action. AndyW ---------------- AndyW, Mercenary Software Developer
From: S Perryman on 29 Jan 2008 05:40
AndyW wrote: > On Mon, 28 Jan 2008 20:14:02 -0800 (PST), topmind > <topmind(a)technologist.com> wrote: >>Until these "special rules" are documented and studied and analyzed, >>we cannot rely on them. And, it sounds like it gets further from the >>"real world". A "mixin" is not readily a real world thing. > They are well documented, a mixin in say a language such as C/C++ is > otherwise known as a struct. In comparison to a class, a mixin has > no methods. A class with methods but no data is a service (basically > a group of related functions). This is an incorrect/corrupted meaning of "mixin" . When first appearing in OO literature in the mid 1980s (OO Lisps - Flavors in particular, LOOPS also I think) , mixin class examples had operations as well as data. A cursory Net search appears to corroborate this too (definition, the concept as expounded by Flavors etc) . Regards, Steven Perryman |