Re: CoBOL moved to OO

From: LX-i (lxi0007_at_netscape.net)
Date: 12/30/03 

Date: Mon, 29 Dec 2003 17:58:11 -0600

Judson McClendon wrote:
> "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.
> Programming around the problem can be extremely difficult, even
> impossible.

That's why you make the compenents do very little. How many times do
contractors have a broken brick? I'm not saying it's as exact a science
as brickmaking, but it can approach that. If you find that this
component does not do what you want it to do, you write or acquire one
that will. With each component containing limited functionality, you're
going to be writing very much, even if you rewrite the whole thing.

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

Do you not envision a world where such precision is possible? Look at
textbook COBOL exercises. These examples are so simple that a novice
programmer can code them (assuming they actually try, etc.). I'm not
advocating taking a complex system and wrapping it as a component - I'm
advocating breaking it up into little pieces, eliminating redundancy,
and have a complex structured system that uses common functionality.

> 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. For any good thing, there is a point of
> diminishing return, beyond which more of it becomes bad. 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.

Are you saying CBSE isn't worth it? A DLL can be a component - you swap
out the common code, and you don't have to risk opening up a whole lot
more code to get the new functionality. I don't see how that's a bad thing. 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant Pages

  • Re: CoBOL moved to OO
    ... just as civil or electrical engineering ... > the supplied functions to access data fail, it can be relatively easy to ... can not only obtain the functionality I require, I can get it "in spades"... ... > true for data encapsulation, logical abstraction, or anywhere else. ...
    (comp.lang.cobol)
  • New OO module idea - looking for suggestions
    ... I've been working on a module that provides encapsulation, inheritance ... Another key piece of functionality is that when a method is overridden ... perl developer to explore and perhaps even enjoy some of the features ...
    (comp.lang.perl.modules)
  • OO and change was Re: Cobol News - Microfocus and AcuCOBOL
    ... I take no responsibility for what MicroSoft do with their ... really are an OO programmer) previous methods need not to be ... That is arguably one of the fundamental reasons for encapsulation, ... Components encapsulate functionality. ...
    (comp.lang.cobol)
  • Re: The Gist of Object Oriented Programming
    ... > In addition to which you should have some notion of encapsulation ... > components except through well-defined interfaces. ... functionality and its required data into classes, ... so that solving a really big problem merely involves solving a few small ...
    (comp.lang.cpp)