Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 02 Jun 2006 22:12:41 GMT
Message-ID: <tJ2gg.16666$A26.385030@ursa-nb00s0.nbnet.nb.ca>

Sasa wrote:

> Bob Badour wrote:
>

>> This 'domain logic' to which you refer. What does it do that is not 
>> entering, manipulating, reporting or deriving data? Of that which 
>> remains, what does not interface with the external world through some 
>> device or another?

>
> I'm not sure what are you asking me. To me, very rough examples of
> domain logic could include:
>
> - data and rules for calculating yearly tax income in case of tax
> application

That's data derivation.

> - data and rules for deriving employee salaries in case of salary
> calculator

That's data derivation.

> - letters, words, paragraphs, fonts etc. and related operations in case
> of text editor

That's data manipulation.

> - keywords, identifiers, syntax and semantic analysis and target code in
> case of compiler

That's data derivation.

> etc.

I didn't ask for examples of deriving or manipulating data. I asked for what parts of domain logic are not those things. If domain logic is simply data management, doesn't it make sense to leverage the power of a data management system for domain logic?

> The rough general description, as I see it, would be that domain logic
> consists of data and behavior. I think that OOP advantage is the
> possibility to combine data and behavior, together with fairly rich
> reuse and decoupling mechanisms.

Instead of regurgitating meaningless pap, why not simply and directly answer the questions I already posed? The questions are simple enough.

Depending on your definition of behavior, your answer above is either gibberish or entirely uninteresting. I fail to see how an ad-hoc collection of features for constructing large unpredictable state machines out of many smaller state machines is especially advantageous for anything other than creating large unpredictable state machines.

> Feel free to correct me if I'm wrong.

You didn't say anything substantive to correct.

Being relatively inexperienced and
> having worked most of my programming life with OOP I am aware that I'm
> possibly misleaded, and I'm open to any alternatives - so any counter
> arguments, alternatives, links, references, etc. are very welcome.

Learn predicate logic. Learn the relational model. Learn how to recognize sophistry. Search out things like 'tutorial d', 'the third manifesto', read a copy of Fabian Pascal's _Practical Issues..._ book. Search on EWD and do some spelunking in the Dijkstra's writings. Learn some formal methods. While you are at it, I highly recommend Gilovich's _How We Know What Isn't So_. Received on Fri Jun 02 2006 - 17:12:41 CDT