Re: Mixing OO and DB
Date: Wed, 5 Mar 2008 00:35:23 -0600
Message-ID: <2008030500352340194-unclebob_at_objectmentorcom>
On 2008-03-04 16:43:03 -0600, topmind <topmind_at_technologist.com> said:
> On Mar 4, 2:19 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
>> On 2008-03-03 11:04:14 -0600, topmind <topm..._at_technologist.com> said
>> Wrapping query results into objects can sometimes be more work than >> it's worth. Other times it saves a great deal of work because of the >> increase of abstraction level.
>
> How are you measuring "work" here?
Sometimes you just want to fetch a few columns and manipulate them directly in one place. Other times you want to put those columns into an object that has methods that conveniently manipulate them over a wide part of the app.
> Reading time, or code-changing
> time?
Code changing time is composed primarily of code reading time. Code is read much more than it is written. Much more.
> While I will agree it may provide a slight improvement in
> reading speed[1] of a given routine,
Which means it also provides improvent in code writing and changing time since writing and changing code *always* involves a significant amount of code reading.
> it is certainly NOT a code
> editing simplifier because you have to jump down to the wrapper method
> to make changes.
Without the wrapper, you have to jump to the code that uses the datarows to make changes. No difference unless the datarows are manipulated in more than once place. At least in the object you know exactly where the data rows are being manipulated.
> We thus have 3 factors to consider:
>
> 1. Read-time in target routine
Which overrides because reading is the majority of what we do.
>
> 2. Hunt-time when looking for sub-methods (more methods equals more
> time). This is both when going to find a particular wrapper and any
> time we need to look for routines for other purposes, where the name-
> space is cluttered with wrappers.
That used to be true in the '60s (and for tools that still live in the '60s) Nowadays we have IDEs that find functions very rapidly.
>
> 3. Change points
>
> Wrapping gives a slight gain in #1,
No, sorry, wrapping gives a benefit in #1. It is easier to understand code that manipulates a wrapper than it is to understand code that reaches into rowsets.
Only for ancient tools. The loss in modern IDEs is close to zero.
No, #3 is a wash. If you must make a change to the wrapper, then you'd have had to make a change to the unwrapped code anyway.
Sorry, but your math is bad. There is a net gain. A rather large one.
> Unless you can argue there is a *huge*
> reading advantage,
There is.
> time-and-motion studies will not back you.
Have you ever played back a recorded editing session? Notice how much time is spent reading as opposed to writing. The difference is startling.
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Wed Mar 05 2008 - 07:35:23 CET