Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Fri, 02 Jun 2006 22:12:41 GMT
Message-ID: <tJ2gg.16666$A26.385030_at_ursa-nb00s0.nbnet.nb.ca>
Sasa 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
> - 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.
> Feel free to correct me if I'm wrong.
You didn't say anything substantive to correct.
Being relatively inexperienced and
> 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 Sat Jun 03 2006 - 00:12:41 CEST