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

From: Sasa <sasa555_at_gmail.com>
Date: Sat, 03 Jun 2006 08:34:55 +0200
Message-ID: <e5rai4$eni$1_at_sunce.iskon.hr>


Bob Badour wrote:

>> 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?

Call it what you like - these are examples on what I mean't when talking about domain logic.
Would you implement all of these entirely in the DBMS? Do you think DBMS is best suited platform for developing a text editor?

>

>> 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.

If I understand correctly you say that DBMSes are best suited for data entering, deriving, manipulating and reporting. Then you proclaim that everything is data entering, deriving, manipulating and reporting. Consequently you conclude that DBMS are best suited.

In that sense you're reasoning tactic is similar to mine. I say that business logic consists of data and behavior. I then state that as far as I know OO is best suited for this - hence the OO approach.

It doesn't seem this will get us anywhere :-(

> 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.

Are you saying state machines are entirely bad? The running app goes through different states. What is then best suited to describe this if not state machines?

As for "unpredictable" qualification - I don't know where that came from, or what does it mean. Surely you're not saying that every OO program amounts to "unpredictable" state machine?

> 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_.

Thanks a lot. Despite our different views I appreciate the fact that you have taken the time to discuss with me in this and other posts, as well as provided these tips.

Sasa Received on Sat Jun 03 2006 - 08:34:55 CEST

Original text of this message