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 29 Jan 2008 18:59 AndyW wrote: > 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] I agree, it may be largely subjective. My head fits relational better. > > >In OOP it is not > >easy to maintain all the necessary links/classifications to provide > > What link/classifications ? In the car parts example, example links may be between part 72 and it's inventory quantity. Or the fire/safety people may want to know what kind of federal disposal regulation classification a given part or part's material/chemical has. (There may be a "regulation" table that tracks info about regulations, such as which gov't agency created it, when it goes into affect, when it expires, etc.) > > 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). This is *relative*. If you want to count how many people are drinking coffee, then empty cups have no use for you. You consider the "cup of coffee" as a unit for the task at hand. We model CONCEPTS that serve the task at hand. Whether those concepts are single physical objects or not may be mostly irrelavant. If I need to create a Zark "thing" to monitor them, then I do it without worrying whether Zarks are composed of 3 Norks and 2 Gribs. In my apps, the queries tend to create a task-specific view that rids everything else except what that task needs. It is a FUNNEL of sorts. That's what abstraction is about. Abstraction is not about modeling the parts of the real world, but modeling what and ONLY what you want to deal with at a given time. You pull out what is essential to the task and only what is essential to the task. > > 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. I find it the opposite in well-designed apps: the relationship is in the data, not hard-wired into app code. It's easier to sift, study, edit, and report-on that way. > > 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) Often everything is connected to everything else. Thus, if you bring in every component in the chain, you have to load bunches and bunches of stuff. Performance issues aside, how do you keep all this "fresh"? What if somebody deletes it while you are processing it? The transactional nature of RDBMS generally provide techniques to deal with the freshness issue. Usually one takes a single snapshot (query result) and works with that for the duration of the task. > > 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. But payments are related to sales orders and shipping orders which relate to vendors which relate to parts catalogs, etc. There may even be circular references. It is usually not practical to load the whole kitten kaboodle, let alone the staleness problem mentioned above. The real world relationships are mostly a graph, not a tree. Thus, how does one decide where to stop loading in the meandering graph? (Some claim they can force stuff into a DAG of some sort, but they seam to have some of the same practical limitations that trees do.) > > 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. OO'ers seem to want Bubble Memory (hyped in the 80's) so that objects stay permanently in RAM. However, you're simply reinventing navigational databases that way. One dances around on nodes (objects), and related components are a pointer hop away. Dr. Codd found these to be unruly, and the rest is history. > 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 -T- > > ---------------- > AndyW, > Mercenary Software Developer
From: AndyW on 31 Jan 2008 00:29
On Tue, 29 Jan 2008 10:40:14 +0000, S Perryman <q(a)q.com> wrote: >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) . Perhaps, but I used to use the idea back in the 80s as well, and the word mixin to me meant a [data] structure that was used with many things (mixed usage structure) and may or may not have an interface (set of methods/functions). Because one has a service class that has methods and no data [not counting local variables to maintain basic state], there is no need to have methods in a mixin. Therefore it generally remains solely as a data class (in general) and can be used by services and even objects themselves. From the OO perspective these two items deal with the case where constructs are not deemed to have 'identity, state and action'. Andy ---------------- AndyW, Mercenary Software Developer |