Re: CoBOL moved to OO
From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 12/29/03
- Next message: William M. Klein: "Re: CoBOL moved to OO"
- Previous message: Richard: "Re: Date manipulation"
- In reply to: Judson McClendon: "Re: CoBOL moved to OO"
- Next in thread: LX-i: "Re: CoBOL moved to OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 30 Dec 2003 11:49:43 +1300
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:5839a628f9762d542fde0617c64c4412@news.teranews.com...
> "LX-i" <lxi0007@netscape.net> wrote:
> >
> > This is why component-based software engineering (CBSE) is, I believe,
> > what will subsume both structured and object-oriented. Researchers,
> > professors, scientists, and other academics are defining this (CBSE) as
> > an engineering discipline, just as civil or electrical engineering
> > would. These components do very little in and of themselves.
>
> Pardon me, but I think this misses the point. In a procedural system, if
> the supplied functions to access data fail, it can be relatively easy to
> code around, because the data behind the functions isn't completely
> hidden. But when you completely encapsulate that data into an 'object',
> and you have a supplied component fail (it may be purchased and
> inaccessible), or you need to access the data in a way not supported
> by the supplied methods, you are up the creek without a paddle.
No, you are simply used the WRONG component.
You select components based on their specified Properties, Methods, and
Events. You know BEFORE you implement them WHAT they will do. (You may never
know HOW they do it, any more than you may know the intimate details of
exactly HOW electricity is delivered to your house.(Does it affect the use
of it, if it was generated from a wind farm, a nuclear plant, a geothermal
bore, a hydro dam, or a solar panel?)).
I have used third party components for over four years now and NEVER had one
fail. They do what they are specified to do, just as a brick does what it is
specified to do. On one occasion I requested an extension to the existing
functionality of a particular Method. The writer gave it to me within 2 days
and never charged for it as he said it "enhanced the marketability" of his
component.
To procedural programmers the idea of not being able to maintain code is
anathema. It requires a large mental adjustment to get over the "not invente
d here" syndrome and trust other people's work as you trust your own. Yet
the benefits of doing so are manifold.
I have one lifetime. I do not expect to become expert in EVERY field of
endeavour which I may need to draw upon in order to create useful computer
systems. By using previously debugged and tested encapsulated components I
can not only obtain the functionality I require, I can get it "in spades"...
Very often a given component (which may be provided by someone who has spent
say, 20 years, in a particular area of specialist expertise) will provide
facilites (Methods and Properties) that I could never have envisaged. I
don't HAVE to use these facilities but it is nice to know they are there if
I want them (now or later...).
It is you, Judson, who have missed the point. The point is that encapsulated
components can provide functionality that does NOT REQUIRE
maintenance...ever. If the system requirements change radically, the
component may be replaced; it is seldom modified (in the case of third party
components you don't have the source code, and probably neither know nor
care what it is written in anyway, so you COULDN'T maintain it.)
The reason these components can provide such fail safe functionality is
because they ARE encapsulated and nobody gets to mess with them. In other
words, they are stable and their capabilities are KNOWN.
(This is a foreign and alarming concept to most procedural programmers, who
are orking in an environment where things require "maintenance" every
day...)
Guess which one is most cost effective?
> Programming around the problem can be extremely difficult, even
> impossible.
Not in my experience.
>Wearing seat belts can protect vehicle passengers in an
> accident. But if the vehicle goes into water or catches on fire, a
> seatbelt that won't unlock can kill you. But such simple locks can be
> made very reliable, pretty close to foolproof. Now, what if you force
> passengers to wear well secured straight jackets? You might save
> more lives sometimes, but you are certainly going to cause so many
> problems that it would never be accepted. Extreme encapsulation
> can do the same thing.
The above is such total rubbish that I won't dignify it by refuting it.
> For any good thing, there is a point of
> diminishing return, beyond which more of it becomes bad.
What about sex and drugs and Rock 'n' Roll <G>?
>This is
> true for data encapsulation, logical abstraction, or anywhere else. It
> is not just knowing the rules, it is also knowing when you can and
> must break them. Because no rule ever made by man is perfect, and
> there are times for any such rule when it cannot be applied, or
> perhaps, further applied, to benefit.
Hmmmm...food for thought there...
Here's a rule, made by man, which can be applied without exception and is
always true...
"A fart in a bottle can never be rattled."
Here's another one...
"If you hang your arse out the window, you cannot go down the street and
throw stones at it."
Finally...
"Beware of people who tell you rules are made to be broken, and should be,
but only when THEY say so."
Pete.
- Next message: William M. Klein: "Re: CoBOL moved to OO"
- Previous message: Richard: "Re: Date manipulation"
- In reply to: Judson McClendon: "Re: CoBOL moved to OO"
- Next in thread: LX-i: "Re: CoBOL moved to OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
