Re: Mixing OO and DB
Date: Mon, 3 Mar 2008 22:47:07 -0800 (PST)
Message-ID: <10aa3fce-1ecc-4b3e-be2c-ff85d4a16bc4_at_h11g2000prf.googlegroups.com>
Robert Martin wrote:
> On 2008-03-03 10:38:36 -0600, topmind <topmind_at_technologist.com> said:
>
> >
> >
> > Robert Martin wrote:
> >> On 2008-02-28 10:36:03 -0600, topmind <topmind_at_technologist.com> said:
>
> >>> One-usage wrappers are a waste of code in my opinion and just
> >>> creates tedious red-tape accessor clutter.
> >>
> >> Not if they are explanatory.
> >
> > Like I suggested elsewhere, use *comments*.
>
> No, please don't. If you have something to say, try to say it in your
> programming language. Only use a comment when you cannot find a way to
> simply express yourself in your programming language.
>
> > 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.
>
> > 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.
foo = bar + adsfsdf() blah go ga do dad zarg(aasdf, sddfsdf, sdf, asdf, asdf)}
The second often requires a lot of parameter maintenance which doesn't show up here, and this is also clutter and busy work and a source of potential typos. It adds more parts to the machine.
Note that I sometimes do split up functions even if they are called only once. It depends on the situation.
>
> 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.
>
> 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?
>
> > I cannot vouch for every eyeball out there, but it slows down
> > my reading to have all that extra junk in there.
>
> I'd bet you it doesn't.
So you know my mind better than me, eh? Professional clairvoyant and OOP author? Nice. Please let me know when "OOP for Agile Astrologers" comes out. (To be released after "Unidentified Flying Object Oriented Programming")
>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
-T- Received on Tue Mar 04 2008 - 07:47:07 CET