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

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Sat, 03 Jun 2006 00:46:29 GMT
Message-ID: <FZ4gg.52919$P2.46597@tornado.ohiordc.rr.com>

Bob Badour wrote:
> 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_.

Sasa, a friendly suggestion: abandon any attempt to explain what you think the term "domain logic" means. Familiarize yourself, instead, with the modern theory of types... after you've finished steps 1 and 2. The topics are not very broad - each can be summarized on a single page - but they're painstakingly precise.

You'll be glad you did. Received on Fri Jun 02 2006 - 19:46:29 CDT