Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???




"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5n7tqmFgjcluU1@xxxxxxxxxxxxxxxxxxxxx


"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:13gsmjsr5p3572@xxxxxxxxxxxxxxxxxxxxx

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5mtjd5Ff4j98U1@xxxxxxxxxxxxxxxxxxxxx
[snip]
It 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
based
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 same
functionality if they were written in procedural COBOL. (I couldn't
implement the COM wrapping in procedural COBOL for a start. It is
inherited
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 and
can only be used through its interface. Even the individual internal
methods
are encapsulated. Properties are accessed through GET and SET methods,
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
be.
They have to be wrapped properly to enable it and that wrapping is most
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...
why
is the command line a show stopper? Because you need to shell to use it...
it is NOT an instantiable interface), but procedural modules are not. It
is
all about how you can interface and build them together. True components
can
be built into systems with other components that are not even written in
the
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>



.



Relevant Pages

  • Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
    ... What of components written in procedural COBOL? ... Our definition of OLE describes services as being ... can only be used through its interface. ...
    (comp.lang.cobol)
  • Re: Creating OCX files
    ... COM objects and components take their origins from OLE 2.0 spec. ... and OLE controls architecture. ... COM object is a program unit that implements IUnknown interface. ...
    (microsoft.public.dotnet.general)
  • Re: Linking and building
    ... The typelib is the interface for the "Standard OLE Automation" library. ... There are a whole suite of OLE components, most of which are updated by OS ... OLE Handlers for each OS and its MDAC configuration. ...
    (microsoft.public.vb.general.discussion)
  • RE: Create file using drag and drop
    ... I suggest you could use OLE Drag and Drop com ... The Source of the drag-drop is represented by the IDropSource interface. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Creating OCX files
    ... COM objects and components take their origins from OLE 2.0 spec. ... and OLE controls architecture. ... COM object is a program unit that implements IUnknown interface. ...
    (microsoft.public.dotnet.general)