Re: Did I write a good (efficient) program?

"Michael Mattias" <mmattias@[EMAIL PROTECTED]
> wrote in message 
news:B2tIj.20982$xq2.2197@[EMAIL PROTECTED]
> "Howard Brazee" <howard@[EMAIL PROTECTED]
> wrote in message 
> news:qbi4v3lh2qh46k37lsl1v3pg0f4jppaod8@[EMAIL PROTECTED]
>> On Tue, 01 Apr 2008 12:44:49 GMT, "Michael Mattias"
>> <mmattias@[EMAIL PROTECTED]
> wrote:
>>
>>>1. Does it work?
>>>2. Is it *relatively* efficient?
>>>3. Is it maintainable?
>>>
>>>You need a "yes" answer to all three questions to have well-written
code.
>>
>> Of course, the industry has changed considerably - which has changed
>> how we grade these.
>
> I don't about "industry" but I have always weighed 'maintainability'
very, 
> very heavily: When was the last time you saw a program which NEVER was 
> upgraded/enhanced/changed?
>
I have dozens of them :-)

They're called "components"...

Each of them represents encapsulated basic functionality that simply
doesn't 
change. They are building blocks, just like atoms or bricks; you don't 
modify the structure of the atoms to make a different molecule; you just 
combine different atoms differently (or add some new ones).

Components that access or maintain data are most likely to be "volatile". 
That's why I use an n-tier approach to system architecture. Components in 
the DB access layer are virtually "cannon fodder" and can be replaced or 
extended very quickly. (In fact, I am currently evaluating tools that will

automatically generate these components whenever I change the DB 
design...There are some staggering tools available...)

It was this that led me to consider interfaces very carefully. Most of the

time, if you change an interface (maybe add another parameter or parameter

value) it has a serious effect and requires regression testing. If you can

avoid changing the interface you can avoid much of this grief. As Object 
Cl***** can be forced to generate automatic methods for accessing and 
setting their internal properties, this means I can change parameters 
without changing interfaces. This allows me the option to "activate" 
existing functionality that was built in by "up front" design (part of a 
GENERAL rather than SPECIFIC solution, or to add new behaviours  by 
overiding or extending existing methods in a new subclass. (This allows 
"evolutionary" design rather than "up front" design.) I can use either or 
both design approaches, and I never need regression testing.

(It would be VERY difficult to implement such an approach, WITHOUT using 
Object technology...)

Only the control elements that invoke the new or modified functionality
need 
to be tested.

Pete.
-- 
"I used to write COBOL...now I can do anything."