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

"Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message 
news:L9ydncNEK_U0YGjanZ2dnUVZ_ternZ2d@[EMAIL PROTECTED]
>
> "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
> news:65lo9dF2gqp30U1@[EMAIL PROTECTED]
>>
>>
>> "Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message
>> news:l6KdnaVTeOZ762janZ2dnUVZ_rSrnZ2d@[EMAIL PROTECTED]
>> >
>> > "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
>> > news:65k1fkF2gdg4dU1@[EMAIL PROTECTED]
>> >>
>> >>
>> >> "Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message
>> >> news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d@[EMAIL PROTECTED]
>> >> >
>> >> > "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in 
>> >> > message
>> >> > news:65fmhdF2fbsenU1@[EMAIL PROTECTED]
>> >> > [snip]
>> >> >> To modify existing functionality does NOT mean modifying a base
> class.
>> > It
>> >> >> means extending (through inheritance) or over-riding existing
>> > behaviours.
>> >> >
>> >> > The priniples of object-oriented design do not include
>> >> > the use of inheritance to overcome inadequate or faulty
>> >> > design. In such cases, modifying a base class may be
>> >> > unavoidable.
>> >>
>> >> I have never encountered such a situation and do not expect to.
(Guess
> my
>> >> designs are not "inadequate" or "faulty"...:-))
>> >>
>> >> I really don't care about academic "principles of OO design" unless
> they
>> > are
>> >> pertinent to the world in which I live and work; your statement
above
> is
>> >> not.
>> >>
>> >> My own principles (derived from over a decade of real world use)
tell
> me
>> > not
>> >> to modify a Base Class.
>> >>
>> >> So I don't.
>> >
>> > Therein lies the problem, Mr Dashwood! While you advocate
>> > the OO paradigm, you don't actually use it--preferring your own
>> > principles to those of the paradigm. <g>
>>
>> And how is having things work properly, a "problem"?
>>
>> I use the OO paradigm, I may differ with you over interpretation of 
some
>> aspects of it.
>>
>> Fortunately, I don't need your or your Professor's approval, nor
anything
>> written in a text book, in order to make money with it.
>>
>> No problem.
>
> Huh! ... "differ ... over interpretation of some aspects"?
> It's more on the order of I can not find any commonality
> between the OO paradigm and The Dashwood Paradigm,
> except the use of an OOPL. I do, however, find a lot of
> commonality between The Dashwood Paradigm and
> "procedure-based, bottom-up design, with an OOPL";

You have no idea of how I design stuff or the modelling processes I use.
It 
is NOT procedural, it is totally Object based.

It cannot be "bottom up design" when it is approached from a top down 
perspective.

It is not about OOPL it is about a holistic approach which only recognises

Cl***** and Objects at a conceptual AND a programming level.

> and I rather like that; but to call this "OO paradigm" is
> just plain wrong.

OK, I won't call it that if it offends you. I really don't care... :-)

>
> Consider that bottom-up design in procedural programming
> (not to be confused with the procedural paradigm) may be
> used to develop reusable components; but sometimes such
> components do not have a good fit. Using inheritance in an
> OOPL to correct for that makes it better fit; but using
> inheritance in this manner is not consistent with OOD.

And we already established that I don't do that so what are you arguing 
about? (The only point of issue here is your statement that sometimes Base

Cl***** HAVE to be amended. I disagree, (I'd rather scrap a base class and

rewrite it than amend it; I DON'T use inheritance to fix flaws in the
Class 
and would never do that),  and suddenly, according to you (an expert in 
procedural COBOL...) I don't understand OO...?

Have I ever claimed my approach uses OOD in a formal way? No.

I certainly design around Objects (more correctly Cl*****...) but I have 
never claimed I am implementing formal OOD. I use Use Case modelling and 
paper models (along with a number of other approaches if the situation 
warrants it) and I derive Objects with behaviours and properties from
that. 
I really don't care what you call it, but it certainly isn't procedural.

This is just silly and unless you can show some reasonable basis for 
disagreeing, I won't be responding.

A pedantic argumernt based on your understanding of what you THINK I do,
is 
going nowhere for either of us.

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