Object versus non-object COBOL example!

[wahlers]

For discussion following see following forum link containing source code:

Source code:

http://mvshelp.com/cgi-bin/ubb6/ultimatebb.cgi?ubb=get_topic;f=1;t=003263

Don't be intimidated by this source code!

The techniques used in the code above are uncommon to most COBOL programmers.
It is object-based (or more correctly class-based) programming.

Some issues

-> I have seen many discussions on the goto statement.
<- The design of class-based programming completely eliminates the need for goto!

-> I have seen many discussions of deeply nested IF or PERFORM statements.
<- The design of class-based programming completely eliminates the need for deeply nested 'anything'!

-> I have seen discussions on the need for paragraph prefixes (such as: 1000-init, 2000-main, 3000-final, 6000-sub-program, ...)
<- The design of class-based programming is not lineair. Therefore prefixes have no meaning (that is: it is not true that first 1000-init is executed, then 2000-main and then 3000-final ... it all depends on the method being executed).

-> Non class-based programs tend to contain large EVALUATE statements that grow over time.
<- The design of class-based programming eliminates the need for large EVALUATE statements and is much more adaptable to change.

The challenge is this:

1. Try to create a traditional version of the code above (a set of simple table sort routines) with less complexity.
(I can sent an original (traditional) source to those not having the time or will to code. Just sent a mail request to: Mailto: ahlers_wim@hotmail.com )

2. Once you have done that (and only after you have done that)!
Add the option for new sort criteria. Assume following feature is requested by customer, request:
"sort packed-decimal fields on absolute values. Therefore: abs(2) is equal to abs(-2)".


...prediction for traditional procedural code:
1. The number of 'IF' or 'EVALUATE' statements will grow.
2. The existing sorts will be unstable during the implementation process.
3. Internal reuse will degrade.
4. Over time, the program will become more and more complex.
5. The procedural code will have less coding lines then a class-based code but will be more complex.


...prediction for the class-based code:
1. An 'ENTRY' is added for each new feature. But there are no additional selection criteria.
2. Existing sort functionality is completely unaffected.
3. Internal reuse will increase.
4. The 'to-be-added' functionality is completely isolated and therefore does not increase at all the existing complexity.
5. The class-based code will have more coding lines then procedural code but will be less complex.

...of course, with great discipline you can achieve the above with traditional procedural coding as well.
But class-based or object-oriented techniques, when properly used, makes it so much easier.


Regards, Wim.

 

[fredericofonseca]

Could you please explain what aspects of the supplied source are object oriented? I failed to identify them!.

Note that "entry" is NOT object oriented per se.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[wahlers]

Look inside the link mentioned!

About using ENTRY:
This is one of the ways to define a method when you don't have OOCOBOL.


Regards, Wim.

 

[Dimandja]

If I correctly understood what I read in that link, the author is simply trying to get people to code more efficiently, using his coding style. I didn't see anything that is OO, though.

 

[wahlers]

I said class-based not object-oriented.

Class-based programming is characterised by the following:


1. A collection of related private data for one common functionality (a class).
2. The class has a well defined behaviour.
3. This behaviour is implemented through well defined (public) methods that act, indirectly, upon this data.
4. The internal complexity and storage of this data is shielded from the caller (information hiding).


And now for the example involved:

Class : CombSort, specialised class (sub class) of sort.
Methods : CombSort Methods (behaviour).
Data : None (stateless). What you call a static class or function.

Internal complexity is shielded (same as sub routine).
Internal workings shielded and highly reused (look how floating-point fields use the same code for sorting as the characters field).

 

[fredericofonseca]

What!! Changing the rules in the middle of the race!!

Your thread title

Object versus non-object COBOL example!

From your link

from
Source code:

http://mvshelp.com/cgi-bin/ubb6/ultimatebb.cgi?ubb=get_topic;f=1;t=003263

---------- PLEASE READ TEXT ABOVE CAREFULLY ----------

The code below is in the style I normally code.
It is object-based.
Object-based (or object-oriented) coding created modules are:

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Dimandja]

Also, this is glamorized collection of subroutines (CALLED PROGRAMS).

 

[wahlers]

I am not quite sure but I think I know what you are referring to, which is the following:

I did change a line looking like:
object-based (or object-oriented) is...
Into something like this:
Object-based...or, the next level, object-oriented...

Reason:
I changed this line as a reaction on the reply posted by Dimandja.

It looked to me that Dimandja interpreted the original line as:
object-based = object-oriented
And this is not true and it never was my intention to imply this!
The main two words I used were 'object-based' and 'class-based', not to be confused with object-oriented.


Regards, Wim.

 

[wahlers]

To: Dimandja

Exactly right!
As I said before: A class is defined by a collection of related methods for the purpose of some class behaviour.


Regards, Wim.

 

[WMK]

There appears to be to value to what is being asked - but maybe it's because the subject of the thread has nothing to do with the REVISED request.

I am unfamilar with this "class-based" (non-OO) terminology. Is this the author's invention - or is it based on some common terminology that I just haven't heard elsewhere.

The use of the ENTRY statement is really something that should be avoided if anyone is discussion a GENERAL COBOL issue. Although supported (as an extension) in some implementations, it isn't even portable among them (See, for example, the Micro Focus "sticky-linkage" directive).

If one wants to create "localized" data&procedures, COBOL has - since 1985 - fully supported this via the nested program feature. That is, however, generally described as "modular" - NOT "class based" - much less OO.

Bill Klein

 

[wahlers]

To: Bill

Object-based is absolutely not my invention!
And, yes, it does exist. And, yes, it is common terminology.
Just to name some references: See books of Meilir Page-Jones (he, in turn, refers to other authors, academics and literature where the term is defined or used).

Concerning ENTRY's not being portable.
This is mentioned in the source (see: link).
And, yes, this is a way, albeit non-standard, to implement a method (there are alternatives!).
And I use ENTRY's only to implement methods and for nothing else!

And yes, I do use nested programming to define and control local data. But a program using a nested structure is not the same as a class. You made a similar remark.

I do not quite understand your remark:
"There appears to be to value to what is being asked - but maybe it's because the subject of the thread has nothing to do with the REVISED request."

To: all
Many of the questions asked and remarks made are answered in the mentioned PDF document (mentioned on the linked forum entry). This document may clarify some things.


Regards, Wim.

 

[wahlers]

For those still in doubt...

Try a search engine like google and search with the string:
"object-based programming"

I found this on the internet site:

http://www.fact-index.com/o/ob/object_based_programming.html

Object-based programming

Object-based programming, as opposed to object-oriented programming, is a programming paradigm that is centered around the creation of objects and their interactions, but may not have some of the key features of the object-oriented paradigm such as inheritance, encapsulation, or polymorphism, though these features may be able to be emulated in some fashion.

Some languages such as C are unable to inherently provide object oriented capabilies, however with structs, classes are able to be emulated, with function pointers, member functions to clases are able to be created, however, features such as inheritance are difficult to emulate.


Regards, Wim.

 

[WMK]

So which are you trying to talk about?

Class-based
or
Object-based

Your initial post has,

The techniques used in the code above are uncommon to most COBOL programmers.
It is object-based (or more correctly class-based) programming.

or isn't there actually any difference?



Bill Klein

 

[wahlers]

To: Bill

The difference is acedemic:
The class is what you code.
A class is a template.

At run time you can create 1 or more objects from this template. It is objects that are used and manipulated by the (application) users.

So, in short:
You, as a programmer, code classes and not objects. So, technically it should be called class-based programming.

The same for object-oriented programming. It would be more appropriate to call this class-oriented programming.
However, the word 'object' is the most common one, and in practice the word 'class' and 'object' are used interchangeble. Which, by the way, is highly confusing for some poor procedural programmer that (likes to) switch to object-orientation.


Regards, Wim.

 

[Dimandja]

Why not get a properly object oriented COBOL compiler? By the author's own descriptions his techniques try to be OO, but aren't.

Modular programming has been in use for a long time. There have also been other quite successful techniques used since then: distributed, OO, multi-tier, etc...

But I guess the author is on a crusade: object-based, class-based, shock-and-awe (no, he hasn't used this one yet).

 

[wahlers]

To: Dimandja

Why don't you read it all first before you reach a conclusion!

I notice by your crusade that you actually haven't looked at anything other then the replies on the replies on the replies.

...and then please criticise the contents.
Don't make it a my opinion against your opinion war.
That is just a waste of time for the both of us.


Regards, Wim.

 

[Dimandja]

wahlers,

I thought I was critisizing the author - and yes, I read his link you provided.

I have no quarrel with you - I am commenting on the author. Why are you intent on silencing criticism of this person?

I am free to comment and criticise, you know. And I have not begun to criticise you at all - you'd know. I thought you were merrely informing us about this author. I din't know I had to be afraid to criticise him at all.

 

[Dimandja]

I were you I'd let this author speak for themselves. You act as if you own his ideas. Maybe you do?

 

[wahlers]

To: Dimandja

OK! Let's talk contents now...

Following is not my own text but I quote from the book:
"What everey programmer should know about object-oriented design".

Peter Wegner catagorized environments as being object-structured, object-based, class-based, or object-oriented. The first has only encapsulation and state retention: the second add object identity; the third adds the concept of the class; and the last adds inheritance and other properties (polymorphism, genericity, messages).

Liskov made significant progress in the 1970s on the theory and implementation of the abstract data-type (ADT), which forms the foundation of object orientation.

An ADT is a data-type that provides a set of values and a set of interrelated operations whose external definition (as seen by outside users of that data-type) is independent of their internal representation or implementation, See Liskov et al. 1981.

You may wonder what the difference is between a class and an ADT. The answer is that an ADT describes an interface; it's a facade that declares what will be provided for users of that ADT, but says nothing about how the ADT will be implemented. A class is a thing of flesh and blood -or at least of internal design and code- that implements the ADT. Indeed, for a given ADT you could design and built several different classes.

However, object orientation goes well beyond the ADT.

What makes a good object-oriented design? By showing the conditions under which a class implements a true abstract data-type.

Meilir Page-Jones went on to say:

...So the large-number-of-gurus-in-a-brawl approach to defining object orientation didn't yield much fruit. The problem is that the term "object oriented" is devoid of inherent meaning, and so its definition is totally arbitrary.
My view is that a language (or environment) is object oriented if it possesses most of the following properties: encapsulation, information/implementation hiding, state retention, object identity, messages, classes, inheritance, polymorphism and genericity.

--- end of quotations ---

For COBOL programmers just before or in the transitional state I can also recommend the following book:
"Standard Object-Oriented Cobol" by Ned Chapin.
It is dated but still contains some useful information.

For a more academic, and non COBOL, approach I recommend the Eiffel (language) approach.

Dimandja you made a strong point (several times) that nothing what I do has anything to do with OO. Again, I said object-based not object-oriented. But ok...lets ignore that for the moment. What in your view is OO? Or what in your view is the definition of a class?
Either criticise on my contents (the 2 programs, the document) or when I am (obviously) wrong, tell me where or in what I am wrong. Don't just say you are wrong because that is not constructive.

Hopefully this invites you to reply with more concrete criticism.


Regards, Wim.

 

[WMK]

I think that *my* (not necessarily Dimandja's) objection is that this just doesn't offer enough to be worth evaluating the "details".

COBOL has well-defined and commonly (not universally) implemented Object Oriented syntax (including tools - such as debuggers and class browsers).

*IF* someone is interested in Objects (oriented, based, or whatever) *and* they know COBOL, then the thing to do is get a COBOL compiler that supports it - and play with that.

The "criticism" (at least mine) is NOT to the details of what you present - but to the entire underlying thought that there is sufficient value in this approach to merit detailed analysis.

***

Note:
I fully recognize that this is my PERSONAL opinion. However, I have yet to see (in any forum) any support for this being a useful or valuable approach for existing COBOL programmers.

Bill Klein