Re: Mixing OO and DB

Robert Martin wrote:
> On 2008-03-04 00:47:07 -0600, topmind <topmind_at_technologist.com> said:
>
> >
> >
> > Robert Martin wrote:
> >> On 2008-03-03 10:38:36 -0600, topmind <topmind_at_technologist.com> said
> >>
> >>> Using methods/functions in
> >>> place of comments is not economic,
> >>
> >> It's much easier on the eye, and much easier on the brain of the person
> >> reading the code. Since code is read much more than it is written,
> >> this makes it very economical.
> >
> > I generally do not like that style. Pascal programmers used to try to
> > write "self-documenting" names, and it made me appreciate skillful use
> > of comments. And, you are extrapolating your personal preferences to
> > others. I won't dictate how your brain and eyes *should* work if you
> > don't dictate how mine should work.
>
> I think that this:
>
> // Calculate Pay
> Money pay = hours * rate;
> int overtime = max(0, hours-40);
> pay += overtime * overtimeRate;
> if (flags && 0x02 == 1)
> pay *= 1.02; // bump for union dues.
>
> is a lot hard to read than this:
>
> Money pay = calculatePay();
>

No, because like a good newspaper you have the general idea after reading the headline what's in the details. If you want to skip to the next article you can.

>
> >
> >>
> >>> and makes the code unnecessarily
> >>> cluttered with micro-methods, making it harder to find the "meat"
> >>> methods.
> >>
> >> We don't want meat methods. You want many small methods that build
> >> upon each other and tell a story.
> >>
> >> We divide english into smallish paragraphs in order to separate
> >> individual concepts. A thousand line paragraph is an abomination and
> >> indicates a lack of discipline and skill on the part of the author.
> >
> > To mirror a newspaper in a rough sense, I prefer the "headline"
> > technique:
> >
> > //---- Wake Up ----
> >
> > foo = bar + adsfsdf()
> > blah go ga do dad
> > zarg(aasdf, sddfsdf, sdf, asdf, asdf)
> >
> > //---- Shower ----
> >
> > if (asdfsdf() > sfssdf) {
> > foo = bar + adsfsdf()
> > blah go ga do dad
> > zarg(aasdf, sddfsdf, sdf, asdf, asdf)
> > }
> >
> > //---- Shave ----
> >
> > foo = bar + adsfsdf()
> > blah go ga do dad
> > zarg(aasdf, sddfsdf, sdf, asdf, asdf)
> >
> > //---- Get Dressed ----
> >
> > ....
> >
> > Over this:
> >
> > void GoToWork?(){ //look ma, no complex conditionals
> > WakeUp?();
> > Shower();
> > Shave();
> > }
> > void WakeUp?(){
> > foo = bar + adsfsdf()
> > blah go ga do dad
> > zarg(aasdf, sddfsdf, sdf, asdf, asdf)
> > }
> > void Shower(){
> > if {......}
> > foo = bar + adsfsdf()
> > blah go ga do dad
> > zarg(aasdf, sddfsdf, sdf, asdf, asdf)
> > }
> > void Shave(){
> > foo = bar + adsfsdf()
> > blah go ga do dad
> > zarg(aasdf, sddfsdf, sdf, asdf, asdf)
> > }
>
> You are kidding right? The first is monolithic inline code, the second
> is nicely partitioned and self describing. You can't seriously tell me
> you prefer the first to the second.

If each method/routine only has about 4 lines of code, YES, I prefer the first. It works better for me.

> >
> > The second often requires a lot of parameter maintenance
>
> No it doesn't because the second is inside an object where all the
> variables are fields. That's one of the benefits of having objects.

That has nothing to do with "objects". That's "module-level" variables, and is available in many procedural languages. (Pascal has one of the nicer scoping approaches, if you ignore it's annoying "define-first" rule.) And your own examples have at least one two parameters like employee name and ID.

Another case where you over-credit OOP.

>
> > and this is also clutter and busy work and a source of
> > potential typos. It adds more parts to the machine.
>
> So you simply don't believe in partitioning code at all. You'd rather
> have one big monolith. Come now.

No. I like a compromise.

>
> > Note that I sometimes do split up functions even if they are called
> > only once. It depends on the situation.
>
> That's good to hear. I think you should be doing a lot more of it.

I've found the happy medium. I've tried both sides.

> >> We separate programs into methods for the same reason. We want each
> >> method to be trivial to understand. We want it's name to describe it's
> >> function. We want to read the program from the top to the bottom like
> >> a newspaper article. It should start with the big concepts, and get
> >> more and more detailed as your read down through the little functions.
> >> Like a newspaper article, you should be able to stop reading when you
> >> have gotten to the desired level of detail.
> >
> > That's what the headline technique is for.
>
> Nope, sorry, your monoliths are long. You can't get the simple sense
> of what they are doing in a single glance. With small methods you can.

Who is this "you"?

>
> >> A function should be no longer than five or ten lines of code. A
> >> function should have no more than one indent level. The body of each
> >> if statement should call one function. The body of each loop statement
> >> should call one function.
> >
> > Dictated by the Vatican? Does an angry nun beat us on the tush with a
> > ruler if we violate this?
>
> Dictated by a sense of discipline and professionalism. If we claim to
> be professionals, we need to show it by being _neat_.

Now you are going too far: it's a goddam PERSONAL PREFERENCE. Get off your high horse!

>
> -----
> So this whole OOP vs Database debate -- this whole "oop is mad"
> philosophy -- seems to have come down to a preference between small
> partitioned methods and monolithic programs. OO people like to divide
> their programs into many small methods that are as self descriptive as
> possible. Database people like to wad a whole bunch of code into a
> single highly indented function. Is that what you are saying?

Exaggeration. My code is a mix of function sizes, partitioned as I best see fit. And, I don't know if its an issue of OO-vs-procedural since one can split finely in procedural also.

>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Wed Mar 05 2008 - 08:16:34 CET