Thoughts on teaching OO concepts to COBOL programmers
in [Cobol]
|
Prev: Opcodes of RM-COBOL 85
Next: Re Thoughts on teaching OO concepts to COBOL programmers (by razor iruddock@blueyonder.co.uk)
From: Joe Zitzelberger on 11 Apr 2008 01:02 I've recently found myself tasked with teaching a few dozen IBM mainframe COBOL programmers the concepts of object oriented programming. No specific language syntax, just the concepts. These lucky few dinos will find themselves mixing their COBOL back-ends with standard Java apps, J2EE apps, C# apps, or Ruby apps. My specific goal is not to teach any language specific thing (though I might use Java for the examples and kill the J2SE, J2EE and C# syntax with a single invocation of the stone.throw() method). My purpose is to teach the simple "what is an object", "what is inheritance", "what is an interface", "what is encapsulation", et al, so that they have the proper frame of mind to accept the language specific training that will be offered. I was hoping that some of you that have COBOL experience AND Object Oriented experience might share your thoughts on what was helpful in the learning process. Of course, that includes what was not helpful as well. We often learn more from our mistakes than our successes. For example: I've ruled out the traditional "shape" example to explain polymorphism -- you know, the one where you have a "shape" base class with a virtual "draw()" method -- and a "square", "triangle" and "circle" subclass. I ruled it out because some practicing COBOL programmers (for decades even) have never put a graphic onto a screen, only text. (So my simple example went from "shapes" to the "animal" class with the speak() method -- you know the dog subclass says "bark" and the pig subclass says "oink" and the sheep subclass says "baa means no".) But I would really appreciate hearing about your experiences going from COBOL to any OO style of programming. What were your pitfalls, what was helpful, etc. One thing I would really love is if you have good textbook recommendations. If "The Idiots Guide to OO for Cobol Dummies" was the best thing since sliced bread, please let me know, I might go buy a few cases and make the author a slightly happier person. Thanks in advance to all who respond. Either via newsgroup or to zberger at knology.net. I really appreciate your thoughts. Regards, Joe Zitzelberger
From: Rene_Surop on 11 Apr 2008 04:00 Read Cobol books with referenced to MF Compiler (especially NetExpress) from Arranga & Coyle. Nice OOCobol concept. Object Oriented COBOL by Arranga & Coyle. Search through Google and this is what I found; http://books.google.com.ph/books?hl=en&id=posN1cl6XFUC&dq=Arranga+%26+Coyle&printsec=frontcover&source=web&ots=akHzyDCa6q&sig=y_FNjbyA4w0FA0-lf-vUbewa_Rc#PPR15,M1
From: razor on 11 Apr 2008 04:44 Hi Joe A couple of years ago I did a Masters Degree. One of the modules was Java Programming. The tutor used the concept of monsters. We had to model teh concept of using up bullets and taking hits (ie health level). All very interesting, but..... Even though I passed with 90% I was still left shaking my head. I still couldn't combine this new knowledge with my day job which involves Customers, Products, Orders, Invoices, etc, etc. I would readily buy a book that enabled me to re-learn Java but though real- world concepts that I was familiar with. I would not like to have to model the monsters, bullets and health using COBOL either. Its just not anything I would use. Ruddy
From: Robert on 11 Apr 2008 20:14 On Fri, 11 Apr 2008 01:02:32 -0400, Joe Zitzelberger <zberger(a)knology.net> wrote: >But I would really appreciate hearing about your experiences going from >COBOL to any OO style of programming. What were your pitfalls, what was >helpful, etc. One pitfall is they will find ways to turn OO design back into Cobol concepts. It will happen during maintenance, after designers and developers have moved on. Suppose one method requires a logic change. Instead of doing it the OO way, they'll copy and paste the logic into their client program, just to change a few lines. Before you know it, there will be ten slightly different versions of the method. They will say a change to the base method would have required re-testing every application that used it. This way requires testing only one. And an overload is inefficient. If the object is a structure that will be stored in a database row, they'll replicate fields into other structures stored in other tables. Their rationale will be efficiency and simplification. No one will question how redundant unsynchrnized data makes the system simpler.
From: William M. Klein on 11 Apr 2008 22:26
Joe, although it is medium old, I would suggest looking at/for: "Object Orientation for Cobol Programming" by Ray Obin. See: http://www.bookfinder4u.com/IsbnSearch.aspx?isbn=1569280053&mode=direct I couldn't find where to buy new copies, but you might want to check with Micro Focus to see if they have "old" copies for sale. This book uses "traditional" COBOL thinking to explain OO concepts. -- Bill Klein wmklein <at> ix.netcom.com "Joe Zitzelberger" <zberger(a)knology.net> wrote in message news:zberger-C6D5FC.01023211042008(a)ispnews.usenetserver.com... > I've recently found myself tasked with teaching a few dozen IBM > mainframe COBOL programmers the concepts of object oriented programming. > No specific language syntax, just the concepts. These lucky few dinos > will find themselves mixing their COBOL back-ends with standard Java > apps, J2EE apps, C# apps, or Ruby apps. > > My specific goal is not to teach any language specific thing (though I > might use Java for the examples and kill the J2SE, J2EE and C# syntax > with a single invocation of the stone.throw() method). My purpose is to > teach the simple "what is an object", "what is inheritance", "what is an > interface", "what is encapsulation", et al, so that they have the proper > frame of mind to accept the language specific training that will be > offered. > > I was hoping that some of you that have COBOL experience AND Object > Oriented experience might share your thoughts on what was helpful in the > learning process. Of course, that includes what was not helpful as > well. We often learn more from our mistakes than our successes. > > For example: I've ruled out the traditional "shape" example to explain > polymorphism -- you know, the one where you have a "shape" base class > with a virtual "draw()" method -- and a "square", "triangle" and > "circle" subclass. I ruled it out because some practicing COBOL > programmers (for decades even) have never put a graphic onto a screen, > only text. > > (So my simple example went from "shapes" to the "animal" class with the > speak() method -- you know the dog subclass says "bark" and the pig > subclass says "oink" and the sheep subclass says "baa means no".) > > But I would really appreciate hearing about your experiences going from > COBOL to any OO style of programming. What were your pitfalls, what was > helpful, etc. > > One thing I would really love is if you have good textbook > recommendations. If "The Idiots Guide to OO for Cobol Dummies" was the > best thing since sliced bread, please let me know, I might go buy a few > cases and make the author a slightly happier person. > > Thanks in advance to all who respond. Either via newsgroup or to > zberger at knology.net. I really appreciate your thoughts. > > Regards, > > Joe Zitzelberger |