I told you about data types. Now let's tie some of the Object Oriented terms back to what you might know as a COBOL programmer.
Let's talk class.
To begin I'll toss some big words out to make sure to sound important and all knowing:
Instantiation, polymorphism, inheritance, and ummm a few others I've forgotten over the years.
If you read the various OO books you'll find those words seem to be key to understanding what is a class and how to use it.
I beg to differ. As you can probably guess, I'm more of a plain speaking kinda guy.
I think of a class as a master template containing prewritten routines you can use.
To use a class, you load a copy of this master template into memory and store that location into a uniquely named variable so you can reference it.
Now you have access to all of those prewritten routines which were in that template, just by referencing that variable you stored the location in.
Consider it a program you've already called and you have access to each paragraph or section in the program as a callable routine.
That's about all there is to it.
So, take another look at the routine Alex posted about 99 bottles of beer.
It is just a reuseable program with a bunch of subroutines.
We'll cover how to create an instance and call the methods in another post.
So, does this help clear it up a bit?
What are your thoughts on the subject?
Posts
I'm all for making things simple!
ReplyDeleteIf are reading this comment are a procedural COBOL developer - please stop - it is likely to confuse you!
Still here?
I once wrote a book with touched on OO programming. In it I hit the classic issue: Classes are like templates, but the word 'template' has already been consumed by the OO world :( to mean something from which classes are created - for example in C++ :
template <class T>
class Stack {
public:
Stack() { top = -1; }
void push(T i)
{ st[++top] = i; }
T pop()
{ return st[top--]; }
private:
int top;
T st[100];
};
Now - MF Managed COBOL (COBOL for .net and the developmental JVM COBOL) have similar concepts. But they are called generics!
Whilst object orientation is a key software engineering practice and permits a lot of very good things which are much harder without it, the lexicon could do with a bit of a clean up!