Re: Mixing OO and DB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 04 Mar 2008 19:19:54 -0400
Message-ID: <47cdd91e$0$4070$9a566e8b_at_news.aliant.net>

topmind wrote:

> On Mar 4, 3:03 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
> 

>>On 2008-03-04 00:25:43 -0600, topmind <topm..._at_technologist.com> said:
>>
>>
>>
>>
>>
>>
>>>Robert Martin wrote:
>>>
>>>>On 2008-03-03 06:59:57 -0600, "David Cressey" <cresse..._at_verizon.net> said
>>>
>>>:
>>
>>>>>"Bob Bad Odor" <bbad..._at_pei.sympatico.ca> wrote in message
>>>>>news:47cb2504$0$4034$9a566e8b_at_news.aliant.net..
>>
>>>>>>>>Not if they are explanatory. Employee.find("Bob") is a lot easier to
>>
>>>>>>>>understand than Select * from Employee_Table where Name = 'Bob';
>>
>>>>>>How exactly does Employee.find(string) inform the reader that the metho
>>>
>>>d
>>>
>>>>>>will return a single employee with a matching name? People understand
>>>>>>things better when they are informed.
>>
>>>>Well, if you think 'find' is not evocative enough, then you could call
>>>>the function find_single_employee_matching_name("bob");
>>
>>>Um, like what if there are zero Bob's or 200 Bob's in the actual
>>>system? Are you gonna arbitrarily pick one?
>>
>>Don't be silly. find("Bob") will either return the object for "Bob" or
>>it will return nothing. You would only use this method if you knew
>>that there could be no more than one "Bob".

> 
> Then it is an unrealistic example because people's names shouldn't be
> a primary key and/or a unique identifier.
> 
> 

>>If there could be more than one "Bob", then you would use a function
>>like: find_all("Bob") which would return a list of all the matching
>>objects.
>
> Better (except for the wrapping thing)

Why do you continue this? His assertion that find(string) is more understandable was refuted when I asked how it informs one that it matches by name. Received on Wed Mar 05 2008 - 00:19:54 CET