Re: Mixing OO and DB

On Mar 4, 7:14 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> topmind wrote:
>
> > 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 method
> >>>>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?  If one does not
> > understand what the data is, they may end up with such arbitrary
> > decisions, driving the user nuts. (I think Microsoft Outlook has such
> > logic *cough* in it.)
>
> > Such issues tend to be situation-specific such that its not likely to
> > be reusable as-is.
>
> What's even more informative is to look at the verbiage. "Find" evokes
> images of movement going from place to place until one finds what one is
> looking for. Frankly, "finding" is not an important concept from either
> the problem domain or the solution domain and is all about "how" to do
> something.
>
> A relational predicate on the other hand specifies "what" not "how".
> It's a much higher-level construct that is closer to the level of
> intent. In the end, it requires one only specify what is important in
> the problem domain and the solution domain.- Hide quoted text -
>
> - Show quoted text -

Employee.Find(string PersonToFind)

• oh, I'd like to get a list of employees, let's overload that... Employee.Find(Collection<string> people[])
• hmm.... I'm not really "finding", I'm "getting"... Employee.Get(some number of overloads)
• hey --- I like "retrieve" better... Employee.Retrieve(some number of "nullable" params, with no clear semantics on what passing "NULL" means in the context of the function)
• What I really need is a nicely formatted list of employees... Employee.List.Format(<<params>>)
• No, what I'm really doing is "rendering" the list... Employee.List.Render(<<ugh>>)
• Whoa, dude, I need to do all these same things to my Products objects, too. Let me generalize these methods and pass the Object as a parameter, or better yet, use shiny reflection and late-binding and dependency injection and whosiwhatsis... IFindable.Render(<<>>), Format(...), ad infinitum.

... whoops, did I just create a crappy, feature-incomplete, buggy query language?

TroyK Received on Wed Mar 05 2008 - 00:48:01 CET