Re: Real World (Re: Mixing OO and DB)
Date: Mon, 17 Mar 2008 13:43:45 -0700 (PDT)
> topmind wrote:
> >I cannot speak for every domain, but in the domain I am most familiar
> >with: custom biz apps, there is no "real world". It's mostly dealing
> >with intellectual property (money, invoices, laws, etc.) Even a paper
> >invoice is merely a representation and not THE "invoice" per se. Paper
> >is simply an old-style implementation. Before that they maybe used
> >rocks or animal bones.
> >Thus, any operations used are artificial anyhow; all mental
> OK, it's partly abstract and intangible, but in the end money buys
> you food, laws can make people go to jail, etc.
Yes, abstract ideas can *result* in tangible results. Al Kiida belief that the dude upstairs will reward them with wine, women, and song for twisted martyrdom is an abstract idea; but the result was planes smashing into NY buildings.
> In the example I used (numbers of inhabitants of countries in the world)
> the operation of counting all people in a country is also "artificial":
> it doesn't really happen that way. Still, the numbers correspond
> to that operation. Most attributes in your biz apps are more abstract,
> but we can still give them concrete meaning in the same way.
> (This is not to say that we should write code to mimic such operations
> and consider that code to be a specification.)
> >Now, I will agree that OOP generally models how a typical
> >clerk might do it: one paper at a time and one operation at time via a
> >cursor-oriented pencil. Manual labor has no real set operations.
> >Manual labor is generally imperative and thus "navigational".
> >However, that is NOT the same as "modeling the real world", but rather
> >modeling the old fashioned *implementation*.
> You have a point. I agree it would be terrible to define the meaning
> of, say, an attribute, in terms of how particular implementations of the
> operations that use it are executed in detail. But OO doesn't direct us
> to do that. It distinguishes between an operation and its implementation.
> E.g. we can abstract from the details of how collections and operations
> on them are implemented.
which subroutines and stored procedures can perform well.
-T- Received on Mon Mar 17 2008 - 15:43:45 CDT