Why I am not enthusiatic about OO COBOL 
Author Message
 Why I am not enthusiatic about OO COBOL

Much of the data contained in business systems is representational;
that is, it represents an event -- it has no behavior. One of the
descriptions of object-orientation is "objects interacting". Because
representational 'objects' have no behavior, they cannot interact
with other objects. Indeed, it is important that such data never
'change state'.

Example: A sale event creates a sale 'object' that represents the
sale. If the item sold is returned, a sale-return event occurs that
creates a sale-return 'object' that represents that event. The
original sale 'object' has no change in its state.

The behavi{*filter*}abstractions that are discussed as part of
object-orientation do not occur as often in business applications
as in other applications. What occurs frequently in business
applications is process abstractions, such as: validate (edit),
sort, update, report, extract (filter), transform, accumulate, etc.
The combination of these abstractions are the design patterns
of business data processing.

Example: The summarize pattern might be seen to consist of:
    extract -> sort -> accumulate -> update.

Process abstractions may be used in object-orientation by
creating a class with at least one method to define the behavior
of the process. The object data may consist of, as a property,
a collection of objects to hold the representation of events.
Then if a 'summarize' method is invoked with a reference to a
collection of detail objects, the method 'summarize' the detail
and fill its collection with summary objects. Other processes
would use this collection as required by the application.

It would be tempting to call 'summarize' the behavior of an
empty collection, or of an empty file, or a data-item with the
value zero. I think doing so would be a mistake.

Data processing (DP) differs from 'good' OO applications in
at least two ways.

First, DP has a lot of representational data, as discussed
above; OO applications have data in which the state changes.

Second, the nature of 'good' OO applications is that they have
all objects in memory at one time. This may be seen by looking
at OO's roots in simulation and modeling. For these applications,
as I understand them, pairs of timing events are passed to each
of the objects. With the first event, the object examines the
output state of other relavent objects and determines what its
next output state will be. On the second timing event the object
changes its output state. With word processing and spreadsheets,
the events are values or commands entered by a user. Each value
or command changes the state of some object and any object
may be affected, by that change, at any time. An essential
element is that the events are either synchronized in pairs or
asynchronous with propogation.

With DP, only as much data is loaded into memory as is required
and the events that change values often have no immediate effect.
This is because the effect of events that change states are
synchronized to fit a schedule or are asynchronous on demand.

I am not enthusiatic about OO COBOL because the characteristics
that make for 'good' OO applications are different than the
characteristics of most DP.

This does not mean that I feel there are no opportunities to
use OO COBOL. It only means that I feel we must not jump into
OO without first ensuring that an application is well-suited
to OO.



Fri, 07 Jan 2005 16:18:05 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:
> Much of the data contained in business systems is representational;
> that is, it represents an event -- it has no behavior. One of the
> descriptions of object-orientation is "objects interacting". Because
> representational 'objects' have no behavior, they cannot interact
> with other objects. Indeed, it is important that such data never
> 'change state'.

> Example: A sale event creates a sale 'object' that represents the
> sale. If the item sold is returned, a sale-return event occurs that
> creates a sale-return 'object' that represents that event. The
> original sale 'object' has no change in its state.

Yes.  In fact, business operates in exactly this manner.  In business
systems, a debit or a credit transaction is perhaps the most common object
created.  However, it is quite incorrect to say that it will never change
state.  In fact, the requirements of accounting may be that the original
properties of date, original comment, time, and amount never change, but
that certain flags in the object (like posted to the invoicing system) do
change.

Quote:
> The behavi{*filter*}abstractions that are discussed as part of
> object-orientation do not occur as often in business applications
> as in other applications. What occurs frequently in business
> applications is process abstractions, such as: validate (edit),
> sort, update, report, extract (filter), transform, accumulate, etc.
> The combination of these abstractions are the design patterns
> of business data processing.

> Example: The summarize pattern might be seen to consist of:
>     extract -> sort -> accumulate -> update.

> Process abstractions may be used in object-orientation by
> creating a class with at least one method to define the behavior
> of the process. The object data may consist of, as a property,
> a collection of objects to hold the representation of events.
> Then if a 'summarize' method is invoked with a reference to a
> collection of detail objects, the method 'summarize' the detail
> and fill its collection with summary objects. Other processes
> would use this collection as required by the application.

> It would be tempting to call 'summarize' the behavior of an
> empty collection, or of an empty file, or a data-item with the
> value zero. I think doing so would be a mistake.

> Data processing (DP) differs from 'good' OO applications in
> at least two ways.

> First, DP has a lot of representational data, as discussed
> above; OO applications have data in which the state changes.

> Second, the nature of 'good' OO applications is that they have
> all objects in memory at one time. This may be seen by looking
> at OO's roots in simulation and modeling. For these applications,
> as I understand them, pairs of timing events are passed to each
> of the objects. With the first event, the object examines the
> output state of other relavent objects and determines what its
> next output state will be. On the second timing event the object
> changes its output state. With word processing and spreadsheets,
> the events are values or commands entered by a user. Each value
> or command changes the state of some object and any object
> may be affected, by that change, at any time. An essential
> element is that the events are either synchronized in pairs or
> asynchronous with propogation.

> With DP, only as much data is loaded into memory as is required
> and the events that change values often have no immediate effect.
> This is because the effect of events that change states are
> synchronized to fit a schedule or are asynchronous on demand.

> I am not enthusiatic about OO COBOL because the characteristics
> that make for 'good' OO applications are different than the
> characteristics of most DP.

> This does not mean that I feel there are no opportunities to
> use OO COBOL. It only means that I feel we must not jump into
> OO without first ensuring that an application is well-suited
> to OO.

To tell the truth, I cannot figure out what you mean by the rest of this.
What is the significance of the quotations whenever you use the word "good"
in the above?  My comment is sorta: Then use "bad" OO applications.  I have
not a clue about what is good and bad oop.  I have written Cobol for 35
years, and I have written oop Cobol for five, and I have  degree in computer
science, and have written at least 5 or 6 million lines of Cobol (at least
if I cheat and count lines of copy books each time they were used).
However, I learnt oop by converting a couple of big legacy systems, then
wrote some stuff that I sell, I can assure you it does all sorts of really
neat stuff.

If the neat stuff that it is doing for me and my bussiness systems is really
bad OO Cobol, then I'll just have to live with the consequences, I guess.

Donald



Sat, 08 Jan 2005 01:32:36 GMT  
 Why I am not enthusiatic about OO COBOL
Congratulations, Rick.

This is the most succinct demonstration of a lack of a understanding of both
Business processes and OO concepts that I have ever seen.

Keep up with the computer science. It has absolutely no relevance to the
real (commercial) world, and whatever you do, don't start implementing
systems on the lines you have described and then say they are "Object
Oriented"... For you, OO COBOL will forever be a mystery.

Pete.


Quote:
> Much of the data contained in business systems is representational;
> that is, it represents an event -- it has no behavior. One of the
> descriptions of object-orientation is "objects interacting". Because
> representational 'objects' have no behavior, they cannot interact
> with other objects. Indeed, it is important that such data never
> 'change state'.

> Example: A sale event creates a sale 'object' that represents the
> sale. If the item sold is returned, a sale-return event occurs that
> creates a sale-return 'object' that represents that event. The
> original sale 'object' has no change in its state.

> The behavi{*filter*}abstractions that are discussed as part of
> object-orientation do not occur as often in business applications
> as in other applications. What occurs frequently in business
> applications is process abstractions, such as: validate (edit),
> sort, update, report, extract (filter), transform, accumulate, etc.
> The combination of these abstractions are the design patterns
> of business data processing.

> Example: The summarize pattern might be seen to consist of:
>     extract -> sort -> accumulate -> update.

> Process abstractions may be used in object-orientation by
> creating a class with at least one method to define the behavior
> of the process. The object data may consist of, as a property,
> a collection of objects to hold the representation of events.
> Then if a 'summarize' method is invoked with a reference to a
> collection of detail objects, the method 'summarize' the detail
> and fill its collection with summary objects. Other processes
> would use this collection as required by the application.

> It would be tempting to call 'summarize' the behavior of an
> empty collection, or of an empty file, or a data-item with the
> value zero. I think doing so would be a mistake.

> Data processing (DP) differs from 'good' OO applications in
> at least two ways.

> First, DP has a lot of representational data, as discussed
> above; OO applications have data in which the state changes.

> Second, the nature of 'good' OO applications is that they have
> all objects in memory at one time. This may be seen by looking
> at OO's roots in simulation and modeling. For these applications,
> as I understand them, pairs of timing events are passed to each
> of the objects. With the first event, the object examines the
> output state of other relavent objects and determines what its
> next output state will be. On the second timing event the object
> changes its output state. With word processing and spreadsheets,
> the events are values or commands entered by a user. Each value
> or command changes the state of some object and any object
> may be affected, by that change, at any time. An essential
> element is that the events are either synchronized in pairs or
> asynchronous with propogation.

> With DP, only as much data is loaded into memory as is required
> and the events that change values often have no immediate effect.
> This is because the effect of events that change states are
> synchronized to fit a schedule or are asynchronous on demand.

> I am not enthusiatic about OO COBOL because the characteristics
> that make for 'good' OO applications are different than the
> characteristics of most DP.

> This does not mean that I feel there are no opportunities to
> use OO COBOL. It only means that I feel we must not jump into
> OO without first ensuring that an application is well-suited
> to OO.

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.*-*-*.com/


Sat, 08 Jan 2005 02:31:16 GMT  
 Why I am not enthusiatic about OO COBOL

Quote:

> Example: A sale event creates a sale 'object' that represents the
> sale. If the item sold is returned, a sale-return event occurs that
> creates a sale-return 'object' that represents that event. The
> original sale 'object' has no change in its state.

Would it be 'picky' tp point out that I mark original sales items with
sales-return data (credit note number, date, quantity returned) when I
pull out the price, discount and cost data for the returned item.  This
ensures that items are not returned more than once.  It also indicates
the return if the original invoice is re-printed.

In general I entirely agree with you.  OO techniques can be seen as a
solution to problems that Cobol and its applications do not have.  Or
specically have been solved over many years in entirely different ways.

C++ for example arose from C as a way of overcoming C's limitations in
representing data.  C only supports int, float and char in various ways
and arrays.  If, eg, it was required to handle a complex type (or other
struct) then it cannot be done with the normal operators and a library
of routines must be constructed with each operation handled by a routine
or family of routines.

In Cobol a MOVE can work on a record, group, elementary item, redefines,
or renames.  In C an assignment can only operate on the built-in types
and, eg, strcpy() is required for strings.  This leads to 'name space'
pollution as dozens of different libraries must be used for various
types of data.

C++ solves this by using the same names (and names of operators) and
having the compiler detect the types involved and name-mangle to
generate unique routine names - or use dynamic tables at run-time.

The Cobol MOVE does all so this aspect of OO is not required (though it
may be useful).

Quote:
> Second, the nature of 'good' OO applications is that they have
> all objects in memory at one time. This may be seen by looking
> at OO's roots in simulation and modeling.

Of course very many OO applications are inherently single-user and would
have no concept of sharing and locking.  Examples in many books that try
to deal with 'real-world' applications seem to fail miserably to explain
the issues that _I_ and my users need to care about.

I have even seen exaples proposed where the code incorporates the actual
data.  eg a payroll where there was an employee class and then they
instanced 'Jim' and 'Fred' (ie Employee Jim = new Employee(); ).
_Excuse_me_ but _one_ of us is completely clueless about applications.

It might work when it is drawing circles and squares, but this cannot be
translated into actual data processing.

Certainly one can derive classes for data accessing, but it is very
unlikely that there would ever be more than one instance of each class.
This can all be done with called routines incorporating COPY code anyway
and so doesn't provide any _significant_ advantage that overrides the
additional complexity.

In many cases the flexability of Cobol's dynamic calling can avoid the
need that C needed C++ for.  My Report Script interpreter calls the
file(s) being reported on by constructing the appropriate routine names
and calling them.  Statically linked languages can't do that.

Quote:
> This does not mean that I feel there are no opportunities to
> use OO COBOL. It only means that I feel we must not jump into
> OO without first ensuring that an application is well-suited
> to OO.

Exactly, and v.v.  Much of the OO enthusiasm is over GUI which does
appear to be well suited for OO, in fact almost requires it - only
'almost' though.


Sat, 08 Jan 2005 16:42:37 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:



> > Much of the data contained in business systems is representational;
> > that is, it represents an event -- it has no behavior. One of the
> > descriptions of object-orientation is "objects interacting". Because
> > representational 'objects' have no behavior, they cannot interact
> > with other objects. Indeed, it is important that such data never
> > 'change state'.

> > Example: A sale event creates a sale 'object' that represents the
> > sale. If the item sold is returned, a sale-return event occurs that
> > creates a sale-return 'object' that represents that event. The
> > original sale 'object' has no change in its state.

> Yes.  In fact, business operates in exactly this manner.  In business
> systems, a debit or a credit transaction is perhaps the most common object
> created.  However, it is quite incorrect to say that it will never change
> state.  In fact, the requirements of accounting may be that the original
> properties of date, original comment, time, and amount never change, but
> that certain flags in the object (like posted to the invoicing system) do
> change.

Postability is not a behavior of the record of accounting events.
Well I am not suggesting you make any changes, consider the
following:

1. For each class with a 'post' flag, refactor the class to remove
    the flag to a separate class called 'postable'.
2. Create new classes, using multiple inheritance, as
    'postable-whatever', or create 'postable-whatever'
    through single inheritance of 'postable' and aggregation
    of 'whatever'.

What I hope is clear is that the 'post' flag is not a property of
a transaction; but, rather, an artifact introduced into the object
by the process abstraction 'post' and that the transaction,
itself, has no state changes or other behavior.

It is also possible to provide, an overridable method in
'postable', called 'post'; then 'post' in 'postable-whatever'
provides the concrete behavior required by the process
abstraction 'post'.

The options then are:

1. Invoke 'post' immediately after creation of that which is
    'postable'.
2. Defer invoking 'post' until required, in which case:
  a. A process 'post-all-that-is postable' may iterate through
      a collection of 'postable' objects invoking 'post' on each.
  b. A process 'post-transactions' may iterate through a
      collection of 'postable-transaction' objects invoking
      'post' on each.
3. If 2b applies, don't bother with the above; just do what
    you have been doing.

- Show quoted text -

Quote:
> > The behavi{*filter*}abstractions that are discussed as part of
> > object-orientation do not occur as often in business applications
> > as in other applications. What occurs frequently in business
> > applications is process abstractions, such as: validate (edit),
> > sort, update, report, extract (filter), transform, accumulate, etc.
> > The combination of these abstractions are the design patterns
> > of business data processing.

> > Example: The summarize pattern might be seen to consist of:
> >     extract -> sort -> accumulate -> update.

> > Process abstractions may be used in object-orientation by
> > creating a class with at least one method to define the behavior
> > of the process. The object data may consist of, as a property,
> > a collection of objects to hold the representation of events.
> > Then if a 'summarize' method is invoked with a reference to a
> > collection of detail objects, the method 'summarize' the detail
> > and fill its collection with summary objects. Other processes
> > would use this collection as required by the application.

> > It would be tempting to call 'summarize' the behavior of an
> > empty collection, or of an empty file, or a data-item with the
> > value zero. I think doing so would be a mistake.

> > Data processing (DP) differs from 'good' OO applications in
> > at least two ways.

> > First, DP has a lot of representational data, as discussed
> > above; OO applications have data in which the state changes.

> > Second, the nature of 'good' OO applications is that they have
> > all objects in memory at one time. This may be seen by looking
> > at OO's roots in simulation and modeling. For these applications,
> > as I understand them, pairs of timing events are passed to each
> > of the objects. With the first event, the object examines the
> > output state of other relavent objects and determines what its
> > next output state will be. On the second timing event the object
> > changes its output state. With word processing and spreadsheets,
> > the events are values or commands entered by a user. Each value
> > or command changes the state of some object and any object
> > may be affected, by that change, at any time. An essential
> > element is that the events are either synchronized in pairs or
> > asynchronous with propogation.

> > With DP, only as much data is loaded into memory as is required
> > and the events that change values often have no immediate effect.
> > This is because the effect of events that change states are
> > synchronized to fit a schedule or are asynchronous on demand.

> > I am not enthusiatic about OO COBOL because the characteristics
> > that make for 'good' OO applications are different than the
> > characteristics of most DP.

> > This does not mean that I feel there are no opportunities to
> > use OO COBOL. It only means that I feel we must not jump into
> > OO without first ensuring that an application is well-suited
> > to OO.

> To tell the truth, I cannot figure out what you mean by the rest of this.
> What is the significance of the quotations whenever you use the word
"good"
> in the above?

Much of the literature I have read states that OO is not right for
every application, yet suggests that all programming should be
OOP, this is inconsistent. What I see is that some applications
are well-suited or a good-fit for OO; but I am not convinced that
OO is an improvement, or a sufficient improvement, over existing
methods. I also have the notion that the use of OO in some
situations may be really, really bad.

What I did not make clear is that my references to OO refer to
what may be regarded as pure OO and not a hybrid of OO and
imperative non-OO (procedural is too vague for my tatse). In this
sense, pure OO has no records, no groups, and no redefinitions,
except possibly at external interfaces. This is because records
are classes of the record-name, groups are classes of the
group-name, and redefinitions are subclasses of a class-id
which describes the redefined area. Also there are no
copybooks since definitions occur once in classes and reuse
of definitions is accomplished by inheritance.

Hence, my use of 'good' refers to those types of applications
where the use of OO in its purer forms has indisputably
satisfactory results. The antithesis of 'good' is those
applications in which the results may be unsatisfactory.
I do not see the use of pure OO in most business applications
as able to achieve indisputable staisfactory results.

Quote:
>  My comment is sorta: Then use "bad" OO applications.  I have
> not a clue about what is good and bad oop.  I have written Cobol for 35
> years, and I have written oop Cobol for five, and I have  degree in
computer
> science, and have written at least 5 or 6 million lines of Cobol (at least
> if I cheat and count lines of copy books each time they were used).
> However, I learnt oop by converting a couple of big legacy systems, then
> wrote some stuff that I sell, I can assure you it does all sorts of really
> neat stuff.

> If the neat stuff that it is doing for me and my bussiness systems is
really
> bad OO Cobol, then I'll just have to live with the consequences, I guess.

One comment I saw recently discussed sociological effects
(Hawthorne effect) as they may occur in one aspect of
programming. This provoked the question of whether, or to
what extent, the adaptation of languages to provide for OO
may cause programmers to perceive that the use of OO
is better than it really is. It happened to me, briefly, when
I finally began to understand OO. Since then the reality
I see has very little neat stuff.

I do see advantages to using some of the OO features of
COBOL-2002 to accomplish modular programming more
easily than in COBOL-85. Based upon prior discussions, I
think this is close to what you and others are doing -- not
pure OO; but enough of the features to feel comfortable
with your choice.



Sat, 08 Jan 2005 06:17:24 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:

> > Example: A sale event creates a sale 'object' that represents the
> > sale. If the item sold is returned, a sale-return event occurs that
> > creates a sale-return 'object' that represents that event. The
> > original sale 'object' has no change in its state.

> Would it be 'picky' tp point out that I mark original sales items with
> sales-return data (credit note number, date, quantity returned) when I
> pull out the price, discount and cost data for the returned item.  This
> ensures that items are not returned more than once.  It also indicates
> the return if the original invoice is re-printed.

No, it is not 'picky'. The OO solution to separate representational
from behavior could be to implement classes to hold the sale
and sale-return data and a class to aggregate the two. This last
class holds object references to the sale and sale-return objects.
If the object reference to the sale-return is NULL, the item has
not been returned. This is a pure OO solution that adds complexity.
Why do it?

Quote:
> In general I entirely agree with you.  OO techniques can be seen as a
> solution to problems that Cobol and its applications do not have.  Or
> specically have been solved over many years in entirely different ways.

Yes, absolutely! One of the uses of OO in other languages has
been to raise the power of the language up to the level available
in COBOL. I have a 700 page book that discusses the OO
implementation of indexed files in C++ -- a problem COBOL
does not have.


Sat, 08 Jan 2005 08:18:04 GMT  
 Why I am not enthusiatic about OO COBOL
COBOL programs have many data structures i.e. group level items in
WORKING-STORAGE and PROCEDURE DIVISION statements that operate on the data
structures.  In a highly structured program the PROCEDURE DIVISION code
would be in paragraphs that are PERFORMed.  Each of these data structures
and the code that operates on them would be potential object candidates.
From this point of view their seems to be many opportunities for OO
programming in COBOL.

I guess an OO purist would protest that you really should go back and use
OO design principles and redesign from scratch with objects in mind.



Quote:
> Much of the data contained in business systems is representational;
> that is, it represents an event -- it has no behavior. One of the
> descriptions of object-orientation is "objects interacting". Because
> representational 'objects' have no behavior, they cannot interact
> with other objects. Indeed, it is important that such data never
> 'change state'.

> Example: A sale event creates a sale 'object' that represents the
> sale. If the item sold is returned, a sale-return event occurs that
> creates a sale-return 'object' that represents that event. The
> original sale 'object' has no change in its state.

> The behavi{*filter*}abstractions that are discussed as part of
> object-orientation do not occur as often in business applications
> as in other applications. What occurs frequently in business
> applications is process abstractions, such as: validate (edit),
> sort, update, report, extract (filter), transform, accumulate, etc.
> The combination of these abstractions are the design patterns
> of business data processing.

> Example: The summarize pattern might be seen to consist of:
>     extract -> sort -> accumulate -> update.

> Process abstractions may be used in object-orientation by
> creating a class with at least one method to define the behavior
> of the process. The object data may consist of, as a property,
> a collection of objects to hold the representation of events.
> Then if a 'summarize' method is invoked with a reference to a
> collection of detail objects, the method 'summarize' the detail
> and fill its collection with summary objects. Other processes
> would use this collection as required by the application.

> It would be tempting to call 'summarize' the behavior of an
> empty collection, or of an empty file, or a data-item with the
> value zero. I think doing so would be a mistake.

> Data processing (DP) differs from 'good' OO applications in
> at least two ways.

> First, DP has a lot of representational data, as discussed
> above; OO applications have data in which the state changes.

> Second, the nature of 'good' OO applications is that they have
> all objects in memory at one time. This may be seen by looking
> at OO's roots in simulation and modeling. For these applications,
> as I understand them, pairs of timing events are passed to each
> of the objects. With the first event, the object examines the
> output state of other relavent objects and determines what its
> next output state will be. On the second timing event the object
> changes its output state. With word processing and spreadsheets,
> the events are values or commands entered by a user. Each value
> or command changes the state of some object and any object
> may be affected, by that change, at any time. An essential
> element is that the events are either synchronized in pairs or
> asynchronous with propogation.

> With DP, only as much data is loaded into memory as is required
> and the events that change values often have no immediate effect.
> This is because the effect of events that change states are
> synchronized to fit a schedule or are asynchronous on demand.

> I am not enthusiatic about OO COBOL because the characteristics
> that make for 'good' OO applications are different than the
> characteristics of most DP.

> This does not mean that I feel there are no opportunities to
> use OO COBOL. It only means that I feel we must not jump into
> OO without first ensuring that an application is well-suited
> to OO.



Sat, 08 Jan 2005 09:04:49 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:
> COBOL programs have many data structures i.e. group level items in
> WORKING-STORAGE and PROCEDURE DIVISION statements that operate on the data
> structures.  In a highly structured program the PROCEDURE DIVISION code
> would be in paragraphs that are PERFORMed.  Each of these data structures
> and the code that operates on them would be potential object candidates.
> From this point of view their seems to be many opportunities for OO
> programming in COBOL.

Yes, many opportunities.

Quote:
> I guess an OO purist would protest that you really should go back and use
> OO design principles and redesign from scratch with objects in mind.

Current purist seem to suggest wrapping the COBOL with
language du jour; then replace it when necessary. ;-)

There is recognition that OOD cannot find all the classes;
hence the choice is to refactor existing classes when a
suitable class has been found. One of the questions I have
is whether refactoring should ever be so fine-grained as
to effect the representation on external storage or to greatly
affect the speed of conversion from external records to
internal objects.

My current thinking is that  less-than-pure classes create
few, if any, problems in COBOL.



Sat, 08 Jan 2005 10:09:16 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:
> One comment I saw recently discussed sociological effects
> (Hawthorne effect) as they may occur in one aspect of
> programming. This provoked the question of whether, or to
> what extent, the adaptation of languages to provide for OO
> may cause programmers to perceive that the use of OO
> is better than it really is.

When I read your post that started this thread, I thought to myself: "Hmm,
this sounds like an academic dabbling in the real world."

Now I'm sure.



Sat, 08 Jan 2005 11:06:18 GMT  
 Why I am not enthusiatic about OO COBOL



Quote:
> Congratulations, Rick.

> This is the most succinct demonstration of a lack of a understanding of
both
> Business processes and OO concepts that I have ever seen.

I take it you disagree!

Quote:
> Keep up with the computer science. It has absolutely no relevance to the
> real (commercial) world,

I don't agree! I do think that computer science has some relevance. ;-)
I am just not sure how much.

Quote:
> and whatever you do, don't start implementing
> systems on the lines you have described and then say they are "Object
> Oriented"...

Never my intent! Not my desire!

Quote:
> For you, OO COBOL will forever be a mystery.

If things are not a mystery, they are not as much fun!


Sat, 08 Jan 2005 13:29:52 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:
> Much of the data contained in business systems is
representational;
> that is, it represents an event -- it has no behavior. One of
the
> descriptions of object-orientation is "objects interacting".
Because
> representational 'objects' have no behavior, they cannot
interact
> with other objects. Indeed, it is important that such data
never
> 'change state'.

Perhaps it's a mismatch between our respective vocabularies,
but this line of deductions does not make sense to me.

I should in advance warn you that I have very little
OO-COBOL-specific knowledge.  You've made references to
object-orientation in general, though, and that would be the
perspective from which my remarks are made.  From what I have
seen of OO-COBOL, though, it appears to have comparable
constructs to other languages I've used.

Stateless objects are a useful pattern in an object-oriented
design, but they're not the only game in town.  You can get
tremendous benefits out of using one of these instead of a
stateful object.  Eventually, though, you'll have to remember
something beyond a single method call.

Web developers are especially keen on stateless objects,
because of the persistance and performance issues with that
interface.  I've seen projects that are entirely comprised of
stateless objects, but it's a bit of the shell game.  The
browser acts as a presentation object that persists its own
state (however erratically,) simulating a stateful object.

Are these stateless objects and representational 'objects' the
same breed?

___________________

Specifically, I should understand this statement:

Quote:
> Much of the data contained in business systems is
representational;
> that is, it represents an event -- it has no behavior.

Is this equivalent to saying that if you encapsulated this data
within an object, there would be no (reasonable) methods to be
associated with it?

___________________

Quote:
> Example: A sale event creates a sale 'object' that represents
the
> sale.

Great, an example -- abstraction can be the end of any good
discussion.  Just to fix the image a bit more, are you
envisioning a point of sale system?

Quote:
> If the item sold is returned, a sale-return event occurs that
> creates a sale-return 'object' that represents that event.

This sounds like a Return method would be handy to have on this
Sale object.

That object would/should have much of the relavant information
that could be used to flesh out any SaleReturn that you would
want to make.  With more context, I would be able to speculate
if there's even a need for a SaleReturn object, or if this
information can be adequately interfaced by a Sale object.
(For the sake of the next comment, though, I'll assume that the
model warrants a seperate SaleReturn class.)

Quote:
> The original sale 'object' has no change in its state.

This does not appear to be good design to me.  One of the
earlier questions I would ask about a Sale is "what happened to
it."  If it has been returned, a Sale object should be able to
tell me.  Even if the status is not stored proximate to the
original data, or if it's derivative, it still affects the
state of that object.

__________________

Quote:
> The behavi{*filter*}abstractions that are discussed as part of
> object-orientation do not occur as often in business
applications
> as in other applications. What occurs frequently in business
> applications is process abstractions, such as: validate
(edit),
> sort, update, report, extract (filter), transform,
accumulate, etc.
> The combination of these abstractions are the design patterns
> of business data processing.

> Example: The summarize pattern might be seen to consist of:
>     extract -> sort -> accumulate -> update.

> Process abstractions may be used in object-orientation by
> creating a class with at least one method to define the
behavior
> of the process. The object data may consist of, as a
property,
> a collection of objects to hold the representation of events.
> Then if a 'summarize' method is invoked with a reference to a
> collection of detail objects, the method 'summarize' the
detail
> and fill its collection with summary objects. Other processes
> would use this collection as required by the application.

> It would be tempting to call 'summarize' the behavior of an
> empty collection, or of an empty file, or a data-item with
the
> value zero. I think doing so would be a mistake.

__________________

Quote:
> Data processing (DP) differs from 'good' OO applications in
> at least two ways.

> First, DP has a lot of representational data, as discussed
> above; OO applications have data in which the state changes.

There's a bit of chicken-or-egg in this, though?

A common element to projects (I've worked on at least) that
attempt to extend legacy systems, has been to consolidate
information and process from the far reaches of the existing
application suite.  The organization's date would come into a
chute and be transformed and reported into metric tons of
data -- much of it being duplicate or made obsolete by other
transformations.  It appears that the state of the global data
set was changing, and those changes were being appended to the
data, rather than integrated with it.

This is no criticism of the method, though.  It's a reliable
and maintainable way of preserving data integrity.  Building
highly integrated systems is difficult, and sets you up for
perverse and subtle errors that can drive you insane, but those
benefits _can_ be worth it.

__________________

Quote:
> Second, the nature of 'good' OO applications is that they
have
> all objects in memory at one time.

This is simply not true.  Memory is a dynamic affair, and is
probably abused by some OO practitioners, but it's not a good
design principal.

A common mistake for OO sophomores, though, is to equate every
record in their persistant storage to a class, and think only
in terms of instances of those classes.

A quick example:  Say you're looking for Sales made on January
23, 2002 over $100.

1)  You could instance each unique Sale in storage and check
its values, or...

2)  ...you could write a class method that takes your arguments
and returns matching instances, or even a list of identifiers
that can later be used to create the objects.

Clearly method #1 sucks.  Method #2 works, and keeps the
business logic centralized into your Sale class.
Implementation of a SaleQuery class that inherits from a
BizQuery class could further sharpen the distinction between
business, storage and presentation logic.

However, at this point I'm sneaking in some architectural
suggestions, which is not really the strength of OO.  OO is
more about being able to "zone" your code into different
districts.  How you gerrymander your part of the world is
really of no _consequence_ to OO -- only your program.

Quote:
> I am not enthusiatic about OO COBOL because the
characteristics
> that make for 'good' OO applications are different than the
> characteristics of most DP.

I would totally agree that converting a code base to an OO form
is not a persuasive argument for a project -- it doesn't even
get a "contributing factor" nomination from me.

Quote:
> This does not mean that I feel there are no opportunities to
> use OO COBOL. It only means that I feel we must not jump into
> OO without first ensuring that an application is well-suited
> to OO.

Once a target has been named as a project, and I'm in the
technology selection phase, though, my regard of OO spikes.
Unless there is an availibility/quality issue with tools, I'll
pick OO every time.


Sat, 08 Jan 2005 15:38:42 GMT  
 Why I am not enthusiatic about OO COBOL

Quote:

> Much of the literature I have read states that OO is not right for
> every application, yet suggests that all programming should be
> OOP, this is inconsistent. What I see is that some applications
> are well-suited or a good-fit for OO; but I am not convinced that
> OO is an improvement, or a sufficient improvement, over existing
> methods. I also have the notion that the use of OO in some
> situations may be really, really bad.

I do not get this.  Cobol OOP, by nature contains Cobol non-oop.  It has in
it ordinary old procedures, and ordinary old data fields and they can do all
the same things that the Cobol we know and love has always been able to so.
In fact, you cannot write a Cobol OOP program without at least a Prcedure
Division.  You can make that a simple "EXIT METHOD" if the only thing you
want to do is make it an OOP object.

You seem to think that somehow the programer gets contanimated, and as soon
as a they get infected by oop they become incapable of programing a simple
alter statement.  Hell, you are quite welcome to alter GOTO's in methods in
an oop procedure if that is what you really want.  It is a language
extension, not a religion.

Quote:
> What I did not make clear is that my references to OO refer to
> what may be regarded as pure OO and not a hybrid of OO and
> imperative non-OO (procedural is too vague for my tatse). In this
> sense, pure OO has no records, no groups, and no redefinitions,
> except possibly at external interfaces. This is because records
> are classes of the record-name, groups are classes of the
> group-name, and redefinitions are subclasses of a class-id
> which describes the redefined area. Also there are no
> copybooks since definitions occur once in classes and reuse
> of definitions is accomplished by inheritance.

Well then, it is obvious why you do not like OOP. You have invented your own
little construct that does not work, and does not even exist in the real
world.  After doing that, you wrote a nice little essay criticizing it.
There is no such thing as "pure OOP" with no procedural bits. Not in Cobol,
anyway.  You seem to be talking about an academic abstraction that exists
only in your own head.  Why post about it?

I'd be real curious to see some Cobol code that actually did something with
an "object" without using procedural code.

Quote:

> One comment I saw recently discussed sociological effects
> (Hawthorne effect) as they may occur in one aspect of
> programming. This provoked the question of whether, or to
> what extent, the adaptation of languages to provide for OO
> may cause programmers to perceive that the use of OO
> is better than it really is. It happened to me, briefly, when
> I finally began to understand OO. Since then the reality
> I see has very little neat stuff.

> I do see advantages to using some of the OO features of
> COBOL-2002 to accomplish modular programming more
> easily than in COBOL-85. Based upon prior discussions, I
> think this is close to what you and others are doing -- not
> pure OO; but enough of the features to feel comfortable
> with your choice.

Ah.  Well, there is no doubt that the arrival of new tools can certainly
spark some creative juices.

The old saying is that when all you have is a hammer, everything starts
looking like a nail.  Your approach seems to be "lets evaluate this
screwdriver for putting in nails", go into short a dialogue about the mass
of the handle, then s{*filter*}it.

I am glad I have not been comtaminated by academic purity, and can use even
glue and string to make the damand thing work.  I do not have to limit
myself to tools that are "pure", "good", and get good marks in a classroom.

Donald

P.S.  I once heard a(n) (un)civil engineer say to an academic: "It's a
{*filter*}ing hole in the ground, not a watch".  I believe the student was
pounding in a wooden stick, and attempting to put it within 1/10 of an inch
at the time.  The roadbed they were building was 20 miles long.

Donald.



Sat, 08 Jan 2005 21:42:34 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:
> Exactly, and v.v.  Much of the OO enthusiasm is over GUI which does
> appear to be well suited for OO, in fact almost requires it - only
> 'almost' though.

The main advantage of using OO for GUI is that you can get "good enough"
testing without getting a sign-off from every single user testing every
single instance of an object.

But when our object is a business rule, with real money - we can't get away
without much more rigorous testing.   This leads us to prefer isolation of
code over integration as we can test and implement just our change without
having to get sign-offs from half of our world.   With such isolation, the
most widely touted advantages of OO are gone and the cost benefit of
switching to OO is different.   Enough different that nobody can point to an
enterprise CoBOL shop that has moved its business programs to OO CoBOL.



Sat, 08 Jan 2005 21:45:04 GMT  
 Why I am not enthusiatic about OO COBOL

Quote:


> > Exactly, and v.v.  Much of the OO enthusiasm is over GUI which does
> > appear to be well suited for OO, in fact almost requires it - only
> > 'almost' though.

> The main advantage of using OO for GUI is that you can get "good enough"
> testing without getting a sign-off from every single user testing every
> single instance of an object.

> But when our object is a business rule, with real money - we can't get
away
> without much more rigorous testing.   This leads us to prefer isolation of
> code over integration as we can test and implement just our change without
> having to get sign-offs from half of our world.   With such isolation, the
> most widely touted advantages of OO are gone and the cost benefit of
> switching to OO is different.   Enough different that nobody can point to
an
> enterprise CoBOL shop that has moved its business programs to OO CoBOL.

I have five at the moment.

Donald



Sat, 08 Jan 2005 22:47:30 GMT  
 Why I am not enthusiatic about OO COBOL


Quote:
> > But when our object is a business rule, with real money - we can't get
> > away
> > without much more rigorous testing.   This leads us to prefer isolation
> > of
> > code over integration as we can test and implement just our change
> > without
> > having to get sign-offs from half of our world.   With such isolation,
> > the
> > most widely touted advantages of OO are gone and the cost benefit of
> > switching to OO is different.   Enough different that nobody can point
> > to an
> > enterprise CoBOL shop that has moved its business programs to OO CoBOL.

> I have five at the moment.

You have five what?  You can name 5 enterprise sized systems that have
converted their business CoBOL to OO?   What computers and operating system
do they use?  Could you name these companies?   I would LOVE to have
examples.   All I have been able to find so far is PC and server level,
which haven't been sufficient for selling the concept.


Sat, 08 Jan 2005 23:04:17 GMT  
 
 [ 50 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Why I am not reaching callbacks ?

2. I am not deaf, but am I mute?

3. Why Pascal is not... (was: WANTED: COBOL compiler)

4. Why COBOL is not dead ?

5. Any sites using OO (particularly OO COBOL) development on the mainframe

6. MicroFocus OO Compiler (4.0.32) or Any OO COBOL Compiler

7. Enterprise Edition - Why/Why not???

8. Why (or why not) one module per file?

9. OO COBOL/ VIsual Cobol

10. why TCL and why not TCL with JAVA

11. Is this legal and if not why not?

12. why why why oh why why baby

 

 
Powered by phpBB® Forum Software