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


"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:65men3F2h47fuU1@xxxxxxxxxxxxxxxxxxxxx


"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:L9ydncNEK_U0YGjanZ2dnUVZ_ternZ2d@xxxxxxxxxxxxxxxxxxxxxx

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:65lo9dF2gqp30U1@xxxxxxxxxxxxxxxxxxxxx


"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:l6KdnaVTeOZ762janZ2dnUVZ_rSrnZ2d@xxxxxxxxxxxxxxxxxxxxxx

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:65k1fkF2gdg4dU1@xxxxxxxxxxxxxxxxxxxxx


"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d@xxxxxxxxxxxxxxxxxxxxxx

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:65fmhdF2fbsenU1@xxxxxxxxxxxxxxxxxxxxx
[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.

Top down is a term used with the procedural paradigm. <g>

It is not about OOPL it is about a holistic approach which only recognises
Classes 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... :-)

Thank you.


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
Classes 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...?

While I am not certain how the result of rewriting a base class
is any different than amending it, that is not really the issue.

You wrote "To modify existing functionality ... means ... over-riding
existing behaviours". The problem in doing that is that the subclass
is not a proper member of the superclass. The recommendation
is to refactor the superclass to make both subclasses proper
members of the base class. In essence, this is done to correct
a design flaw.

Instead of (admittedly contrived example)
Class-id. DDB-depreciation inherits Depreciation.
Method-id. Calculate-depreciation.
where the method only calculates straight-line depreciation.
Use
Class-id. SL-depreciation inherits Depreciation-method.
Method-id. Calculate-depreciation.
Class-id. DDB-depreciation inherits Depreciation-method.
Method-id. Calculate-depreciation.
So that the over-ridden behavior of the superclass is now in
a subclass and the new behavior is in a separate subclass,
thus making both subclasses proper members of the base
or superclass.

I understand this is not what you do because parts of the
evolving application already depend on the base class.

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

However, advising others to do what is contrary to the
principles of OOD is problematic.

I certainly design around Objects (more correctly Classes...) 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.

Using a RDBMS where the data is in representational form
breaks encapsulation. This is not necessarily a problem, but
the separation of data from its behavior means that the
RDBMS is, in effect, a procedural foundation upon which
the application is built. In OOD, object storage is an
implementation detail and the storage medium and format
are irrelevant outside the application.

However, it is the passing of data ("getters and setters")
among objects that is problematic. If data is shared by
multiple objects then it appears that methods defined in
different classes are performing procedures on or with
that data.

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.

Hey, if it walks like a duck and quacks like a duck .... <g>


.

Relevant Pages

  • Re: Strange question: why cant some classes be inherited?
    ... actual design guideline: ... First IMHO Snyder is correct in that inheritance breaks encapsulation simply ... if any member is non private or any method is virtual. ... behaviors of the base class and violates the Liskov substitution principle, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Strange question: why cant some classes be inherited?
    ... In describing why it would be dangerous, please say why 'private' ... where is the harm of allowing inheritance from ... to the base class (i.e., derived classes should preserve the base class ... allowing the covering up of poor design choices when it comes to heirarchial ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Did I write a good (efficient) program?
    ... The priniples of object-oriented design do not include ... the use of inheritance to overcome inadequate or faulty ... principles to those of the paradigm. ... between the OO paradigm and The Dashwood Paradigm, ...
    (comp.lang.cobol)
  • Re: Did I write a good (efficient) program?
    ... The priniples of object-oriented design do not include ... the use of inheritance to overcome inadequate or faulty ... modifying a base class may be ... principles to those of the paradigm. ...
    (comp.lang.cobol)
  • Re: Did I write a good (efficient) program?
    ... The priniples of object-oriented design do not include ... modifying a base class may be ... I really don't care about academic "principles of OO design" unless they ... principles to those of the paradigm. ...
    (comp.lang.cobol)