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.

 

[Dimandja]

Wim,

You have already described OO - and I did not object to your description.

The point is this style is simply modular - old hat. I don't see the point of repeating this. There is no need to argue about OO, as what you presented is not - and you agree it is not.

I think we agree on everything - except calling the technique object-based or class-based or whatever else nomenclature you have used to describe it. To me it is still modular.

I am sure you know that the foundation of any good OO code is modular programming. So, I am looking at your style in that light. But, when you say that it is OO based in any way, I say that's a stretch.

I did read every line of code you presented. You are promoting rigorous modular programming. But, in many ways your style ceases to be productive and becomes a hinderance (read Bill's and my posts - no need to rehash all the gory details). And this is because your style is trying to protray itself as something it is not.

Don't get me wrong - I admire your enthusiasm about your style of coding. But this is a case of too much for so little return, I think. After coding in your (modular) style, we will not be any closer to OO, than if we coded in just about anyone else's modular style.

Your style just happens to be too exacting for its own good: it forces you to code for OO, but you do not get any OO benefit from it. You even need to get a compiler that allows OO verbs, but no OO benefits. Talk about a waste of time and money.

I'd much rather fork over the money and get a genuine OO compiler, than hack at my old COBOL, only to get an illusion of OO, or class...

Dimandja

 

[wahlers]

To: Dimandja

I agree you should use an OO compiler to use OO.
I agree you can only learn by doing and for that you need an OO compiler.
And...here is the contradiction...you should not learn in a production environment (at least not by yourself...isolated). That is a recipe for failure!

I disagree by saying that this is not (part of) an object based system. Of course it is not complete. But consider this. I coded and implemented a system on this basis in two different environments personally (one in Norway, and one remote implementation in Sweden). These systems have the following properties:

Public methods
Private methods (protected of course!)
Domain methods (for components kind of protected methods)
True objects (dynamic storage allocation by assembler program)
Object Identity
Polymorphism
Class methods
Class introspection
Class library (with automatic documentation)
...it also has some sophisticated components

If you want to know how...details are described in the earlier mentioned PDF document.

Of course, only showing how you can implement a method does not make a source a class. But I am discussing the reverse: Implementing a means for a method is a requirement for a class. And it is this for which I provided the original example. I was addressing procedural programmers and therefore procedural languages.

You are convinced that it is irrelevant because you cannot change programmers in a traditional procedural environment.
In that case I must be the exception...because it did change me...way before I got in contact with OO.


Regards, Wim.

 

[Dimandja]

And...here is the contradiction...you should not learn in a production environment

Now I am confused. What does a production environment have to do with this discussion?

 

[wahlers]

To: Dimandja

Ah...good example of my minor problem (dyslexia):

And...here is the contradiction...you should not learn in a production environment

Should be:

And...here is the contradiction...you should not learn OO using a production environment

(in other words experiment on expense of the customer)


Sorry for that...



Regards, Wim.

 

[fredericofonseca]

Humm.. That is possibly a matter for the customer to decide.

One of my customers (big insurance company) has decided to convert their calculation engine to OO (COBOL) so it could be used from both their active application and a new quote engine written in Java.

No real need to do it, but it made life easier after it was done.

This was a learning exercise for the team involved, but as we were testing in parallel with the production system, and under a already experienced testing team, the customer was reassured of the accuracy of the results.

The fact that the existing calculation engine was a very modular one already did help on the "conversion".

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[wahlers]

To: Frederico


And this is your key part:
...and under a already experienced testing team...

Recipe for disaster:
1. Take a critical system
2. Only programmers with no OO experience and no OO training
3. Take a true OO language (no hybrid)
4. No supervision...of course
5. ...let them hack like hell
6. See how they are doing one day before the critical deadline

Ideal environment (something like this):
1. OO training day ends one day before the project
2. Project is not critical
3. Project has clear boundaries and specifications (OOA and OOD of course)
4. You have only super experienced collegues eager to share their knowledge
5. Super tools
6. Project is about 3 to 6 months with increasing complexity
7. Variaty of domains
8. Project has a deadline...give or take a month
9. You are constantly supported with (bi)weekly evaluations

And you probably are somewhere between these extremes...
I had the disaster scenario in mind...

Of course you can learn, or stronger should learn, OO on the job! But you need support (I actually mentioned this in the original PDF document).


Regards, Wim.