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_at_tornado.ohiordc.rr.com>
>
>
> That's data derivation.
>
>
>
>
> That's data derivation.
>
>
>
>
> That's data manipulation.
>
>
>
>
> That's data derivation.
>
>
>
>
> 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?
>
>
>
>
> 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.
>
>
>
>
> You didn't say anything substantive to correct.
>
>
> Being relatively inexperienced and
>
>
>
> 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_.
Date: Sat, 03 Jun 2006 00:46:29 GMT
Message-ID: <FZ4gg.52919$P2.46597_at_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 Sat Jun 03 2006 - 02:46:29 CEST