Re: Retrieving unnecessary data





Robert Martin wrote:
On 2008-02-19 13:14:31 -0600, topmind <topmind@xxxxxxxxxxxxxxxx> said:

On Feb 18, 9:21�am, Robert Martin <uncle...@xxxxxxxxxxxxxxxx> wrote:
On 2008-02-15 09:46:34 -0600, ShaneLM <shane.nieberg...@xxxxxxxx> said:

One last comment - Topmind mentioned that OO is a fad

No, it's not a fad. �It's deeply entrenched, and isn't going away for a
long long time.

That does not necessarily make it a non-fad.

Webster says: " a practice or interest followed for a time with
exaggerated zeal ".

I will agree it has
become the de-facto way to interact with vendor-pre-packaged libraries
and that will probably stay with us a while (even if it does fall out
of style). As far as what *application* developers actually do, OOP is
*not* entrenched. To them, OOP is treated like vegetables: something
they are taught should be consumed more, but in practice mostly
ignore.

In other words: "practiced without zeal". I think when a practice is
"mostly ignored" it can be safely assumed that it is no longer a fad.

It's more complicated than that. About 30% of developers talk down to
people not using OO as if the others are doing it "wrong and sloppy"
or not enough. About 60% swallow that hype and feel guilty about not
using OO enough. The other 10% know the OO fanboys are exaggerating
OO.


Have you studied TDD? �(Test Driven Development). �Give that a try for

a few weeks and you will see how beneficial OO is when decoupling
modules to make them independently testable.

Evidence that OO makes testing easier?

Function f destroys the world when it is called. Function y calls
function f. How do I test function y? I hide f behind a polymorphic
interface called IF. I implement a fake version of f called MF. I
pass MF to y and tell y to do it's thing. Then I ask MF if f was
called. The world was not destroyed, and yet I know that y will call f.

One can also write a dummy stub function f, or use a dummy database
(dummy world) for testing. I'd prefer a language that allows more
flexible scoping for testing purposes, but most are bound to file-land
out of historical habit. But this is mostly a language-specific issue,
not a paradigm issue.


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

-T-
.



Relevant Pages

  • Re: Grappling, striking or sticks first?
    ... (you have to drink twice: judo needs two to practice. ... dummy is a teetotaler) ...
    (rec.martial-arts)
  • Re: recycling internationalized garbage
    ... def checkEncoding: ... (uni, dummy) ... In practice it's more complicated than that. ...
    (comp.lang.python)
  • Best Practice to handle NULL value in fact table
    ... What is considered best practice to handle NULL values in a fact ... My fact table has a field for PO Number, but not everyrecord ... Should I put a dummy number in those records and add the dummy value ... Or should I leave it NULL and have the Error Configuration handle it? ...
    (microsoft.public.sqlserver.olap)