Prev: object-oriented programming explained in 51 lines
Next: Abstraction & singleton
From: topmind on 31 Jan 2008 18:06


Robert Martin wrote:
> On 2007-12-27 23:00:01 -0600, Matthew Shelton <crash700(a)gmail.com> said:
>
> > I'm just wondering if OOP is a bit overkill for a database app.
>
> OO is a tool. What does the tool do? It helps you manage the
> dependencies between modules. It would be *very* surprising if your
> database application did not have modules whose dependencies did not
> need managing!
>
> Consider, for example, the problem testing your database application.
> You can test the whole application by using it. But how do you test
> the individual modules? How do you test that each query works as it is
> supposed to. How to you test that certain records are displayed in
> just the right way? How do you test that negative numbers appear in
> red, but positive numbers appear in black? How do you test that
> passwords are echoed silently? etc. etc.
>
> How do you test things things independently, if you cannot isolate the
> modules one from another? If you can't manage the dependencies between
> modules, you cannot make your modules testable.
>
> And so, just the basic need of all software, to make it testable, is a
> strong argument for using OO.

Bullhonk. That is largely a matter of language design. I've worked
with languages that easily allow a subroutine to be a file by itself
yet work together as modules when needed. Others sort of bind the
subroutines to a "module file", making independent testing more
difficult. I will agree that the current crop of procedural languages
is not very test-friendly, but this is NOT an INHERANT paradigm fault.
Complain about C or Pascal or something, not procedural in general.

(I think hierarchical file systems are part of the problem. We've
outgrown trees for that, but our tools are still tree-centric.)

Besides, scenario-based testing is often more cost-effective than
routine-level testing. Routine-level testing is labor-intensive and
many companies don't want to pay for that. I choose techniques that
fit typical budgets, not ideal budgets. Your approaches seem geared
toward the second. Perhaps for medical and life-support, such
expenditures are supported. But you are not scope-limiting your OO
claims.

>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com

-T-
 | 
Pages: 1
Prev: object-oriented programming explained in 51 lines
Next: Abstraction & singleton