Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- From: "Rick Smith" <ricksmith@xxxxxxx>
- Date: Fri, 12 Oct 2007 18:00:53 -0400
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5n7tqmFgjcluU1@xxxxxxxxxxxxxxxxxxxxx
[snip]
"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:13gsmjsr5p3572@xxxxxxxxxxxxxxxxxxxxx
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5mtjd5Ff4j98U1@xxxxxxxxxxxxxxxxxxxxx
basedIt is a hard concept for non-OO people to understand and that's why I
more
or less gave up trying to explain it here some time ago. Component
systems do NOT need maintenance in the same way that procedural COBOL
code
does, and there is no need for regression testing.
What of components written in procedural COBOL?
Depends how you define "Component".
As the respondee ("you", taken literally), I choose the
following definition.
-----
component
2. An individual modular software routine that
has been compiled, dynamically linked, and is
ready to use with other components or programs.
-----
Within the context of component software.
-----
component software
Modular software routines, or components, that can
be combined with other components to form an overall
program. A programmer can use and reuse an existing
component and not have to understand its inner
workings, just how to have another program or
component call it and pass data to and from it.
---
Microsoft® Bookshelf® Computer and Internet
Dictionary© 1997 Microsoft Corporation. All rights
reserved. Portions, Microsoft Press® Computer
Dictionary, Third Edition. Copyright © 1997 by
Microsoft Press. All rights reserved.
-----
Thus, it would seem that many "dynamically linked"
COBOL programs would qualify as components.
I have wriiten many components in OO COBOL. I could not achieve the sameinherited
functionality if they were written in procedural COBOL. (I couldn't
implement the COM wrapping in procedural COBOL for a start. It is
from a Base Class)
COM (Component Object Model) is only one possible
component model.
I find it curious that you seem to suggest that COM
requires OO, since COM is object-based.
-----
Object-Based Components: COM
Our definition of OLE describes services as being
"object-based." What does this mean exactly? What
are "objects"-the communication medium between
clients and servers-in the context of OLE? In order
to answer this question, we have to look at all the
various definitions of the term so we can really
understand why an OLE object is what it is. The
concepts that form the idea of an OLE object are
collectively called the Component Object Model,
or COM.
---
Kraig Brockschmidt, "Inside OLE 2", Microsoft Press,
1994.
-----
This book provides examples for creating COM
components in both C and C++. Perhaps I missed
something; but, from what I saw of the interfacing
requirements for C, it seems to me that procedural
COBOL, with the appropriate C-like extensions,
could be used to build COM components.
A component is not just a module. A component is totally encapsulated andmethods
can only be used through its interface. Even the individual internal
are encapsulated. Properties are accessed through GET and SET methods,be.
explicitly or implicity. A component can be dropped into a web page, or
embedded in a desktop application, with no change. It can be instantiated
locally and remotely, and created and destroyed on demand; modules can't
They have to be wrapped properly to enable it and that wrapping is mostwhy
easily implemented through OO. Java Beans are true components, Programs
implementing the COM interface are true components (The "O" stands for
"OBJECT", however :-)), C# Assemblys are (usually) true components (the
exception would be desktop apps where the interface is a command line...
is the command line a show stopper? Because you need to shell to use it...is
it is NOT an instantiable interface), but procedural modules are not. It
all about how you can interface and build them together. True componentscan
be built into systems with other components that are not even written inthe
same language. That is true "Encapsulation".
H'm, "true" anything seems more opinion than fact!
[snip]
I had a feeling you would make this post, Rick :-)
But, you phrased it as you did, anyway! <g>
.
- Follow-Ups:
- References:
- OO COBOL - What if ???
- From: William M. Klein
- Re: OO COBOL - What if ???
- From: LX-i
- Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- From: Clark F Morris
- Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- From: Pete Dashwood
- Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- From: Rick Smith
- Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- From: Pete Dashwood
- OO COBOL - What if ???
- Prev by Date: Re: OO and IBM z series COBOL was Re: Discussions of COBOLphilospphy
- Next by Date: Re: DFSORT (was: Do you have a Knowledge Officer?
- Previous by thread: Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- Next by thread: Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
- Index(es):
Relevant Pages
|