Re: Real World Flunks (Re: Why is Object Oriented so successful)

On Mon, 28 Jan 2008 20:08:15 -0800 (PST), topmind
<topmind@xxxxxxxxxxxxxxxx> wrote:



AndyW wrote:
On Thu, 24 Jan 2008 21:26:24 -0800 (PST), topmind
<topmind@xxxxxxxxxxxxxxxx> wrote:



AndyW wrote:
On Sat, 12 Jan 2008 17:55:50 -0800 (PST), topmind
<topmind@xxxxxxxxxxxxxxxx> wrote:



Daniel T. wrote:
alexcpn <alexcpn@xxxxxxxxx> 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
.