Warning:
What follows will probably be a rather long post.But I am a newbie, and my questions are probably really easy and stupid. Any help will be appreciated.

Right now I am trying to grasp the concept of OOP and basic programming in general. I decided I would undertake designing a simple OO C++ program to assess my understanding of OOP and programming techniques thus far.
Initially, my first priority was to guage my comprehension of the design of OO programs; language syntax and semantics were of secondary concern. However, the more I laid out a mental blueprint of the program, the more I wanted to implement it in real code to test its viability.
What resulted was utter crap that never even compiled.
I then decided to go back to the design phase and make certain that my abstract "blueprint" was sound before deciding to correct any syntax errors.
Now that you know my reasons for going about this minor project, I will soon go on with some details of the design. I may, however, leave out more details such as the actual code or even pseudocode, until such things become more relevant in a later reply.

Anyway, here's what I tried to do:

The type of situation I chose to model was a bank account and the user's interaction with this account via an interface. You could say its something like an ATM type thing, but that's not necessarily what I was trying to model. I chose to use a "BankAccount" class in this program. BankAccount objects will have a variable called "balance" and two functions for manipulating that variable:
deposit() and withdrawl(). Now, one could possibly argue that someone's true bank account is actually just their balance and does not include the modifying functions such as withdrawling and depositing. But probably most people, including myself, would agree that an account is comprised of not only the balance and the place to store that balance, but the functionality of depositing and withdrawling. Without that functionality, a "bank account" is just a useless hole you throw your money in. Besides, without functionality what I wanted to define as a bank-account would really not be a very good thing to model in a computer program.
The reason I mention all of this, is because I wanted to demonstrate the thought process I went through, so I could show what exactly it was I was trying to model. But this is only part of what I was trying to model. I also needed an interface(not a graphical interface though. I am nowhere near that type of concept yet) so that the user can interact with their bank-acount, or "BankAccount". To accomplish this, I created an "Interface" class. Now, I know this was stupid and pointless. One of the main purposes of a class is to provide a blueprint for multiple concrete objects in a program. But I only need one interface.
But I guess I only needed to create one bank account for my purposes too. But actually, there could be good reasons for supporting multiple bank accounts each with different names and values for balance. For example, in real life, each ATM isn't only able to access one bank account. That would be like an ATM existing entirely for the convenience of one person. And even that person would only be able to have one account in this case. So, the reasons for creating a BankAccount class are very obvious and clear to everyone. But I guess the same isn't true for an interface class. So why did I do it?
I only need ONE interface, afterall. At first, I thought about just letting the main() function be my interface. But then I decided that I wanted to try my hand at getting various objects to communicate with one another. Understanding the concept of OOP was the purpose of my program anyway.

I will stop right here before I go on to describe the "Interface" class. If anyone has any advice or comments on what I have written thus far, please tell me. If someone would like to help me with this, I would be very grateful. Feel free to comment on any flaws in my design approach or give some advice.I am tired of typing for now, and I don't know if anyone will want to look into this. My experience with the helpful posters on this forum leads me to believe someone certainly will. If someone would like me to get right to it and post my source code, then I could do that. However, I would like to be sure my design is sound before I get into syntax that much. I am also still trying to figure out a way to get past the formatting on this board, for posting code. Someone pointed me towards a program that is supposed to help, but I have yet to figure out how it works.

Anyway, thank you very much for reading this.

Jack

You weren't kidding with that long post warning, huh?
The bank account example, as you seem to already know, is a perfect candidate for object oriented programming. Your interface class is less of a perfect candidate, unless you're doing something with it that I'm not understanding. You would be better served, if you want to see how classes interact with one another, using a simple repeating menu in main as the interface and finding other things to do with classes that have more to do with the bank account. For example, you could have the BankAccount be a base class, and SavingsAccount and CheckingAccount extend BankAccount, redefine its methods, etc. Nothing wrong with learning a little inheritance.

To see how Objects can interact with one another without inheritance, you could have another class AccountHolder, which may have an array of BankAccounts, or a CheckingAccount and a SavingsAccount and a regular BankAccount, or whatever. If you want to be crazy, have an Array of BankAccounts and have some of the items be CheckingAccounts and some be SavingsAccounts, this way you can learn some great polymorphism techniques.

The interface could have a menu something like this:

Person: SN
Choose an option:
1. Withdraw
2. Deposit
3. Change Person
4. Create new account

Fun exercise. Thanks for posting. Good luck,
SN

Thank you for reading all of that. I do apologize for the length. You gave some really good ideas. But the problem is, I don't know how to do inheritence or arrays. I was afraid either one of those would come up. Any ideas as to how I might approach this without utilizing those? Or should I just give up and go learn arrays and inheritence?

Jack-
You don't need to know either for your particular application, but sooner or later you will HAVE to learn arrays...It won't take you very long. Essentially, an Array is just a convenient way to keep several related variables together. An array allows you to refer to several variables of the same type (char, int, Object, whatever) by using only one variable name. For instance, if a user inputs three numbers, and you don't want to have three variables like
int num1;
int num2;
int num3;

You create an array of integers
int num[3];
3 defines how many numbers you can put in the array.
Although the three numbers are lumped together in an array, you can still reference them individually by what is called the index. This is the number in the brackets. The index is a number from 0-(size-1).
The variable num[index] acts just like a regular variable, so if I want to do something like cin>>num1; only with arrays, I just do cin>>num[0];
Then I can print the first number the same way:
cout<Or I can print all three numbers one at a time or in a loop:
cout<cout<cout<or
for (int i=0; icout<This is a starting off point. I'm sure there are more resources available on the web for you to learn more.

If, however, you are set on doing this without arrays or inheritance, you can do so. Make the BankAccount class like you've described it, and make a person class have an integer idNumber and a BankAccount. This way you will see how classes interact with one another without inheritance, which you can save for a later day when you're ready to learn more about OOP.

Hope this helps,
SN
P.S. To others who will undoubtably find fault with my description of arrays, keep in mind that the description is not meant to be complete nor always true, just a place to start off from.

Let me suggest that you take an iterative approach (regardless of what you intend to implement).

By that I mean:

design a little, code a little, test a little, refactor a little, test a little.

And I ***DO MEAN*** a little - code added or modified at each iteration should be no more than 5 or 10 lines.

You will do this hundreds (if not thousands) of times to produce a real project.

This really allows you to easily tell if the system is working as you think it should, and backtrack if necessary.

HTH, Guy

My response is not to any specifics of your question, but about a programming 'habit' that many programmers don't have.

What made me think of this was your comment regarding your first attempt at this program "What resulted was utter crap that never even compiled". Reminded me of my first program and my first response to the 51 errors that I received. To me, your comment implied or at least suggested the possibility that you wrote the entire program then tried to compile it.

For some reason many people do that. I have known programmers that would write a thousand lines of code before they ever submitted it to a compiler.

Even before OOP, I learned the habit of writing a little bit of code and then testing it before I go on to the next bit of code. I never thought about it until someone pointed out that this was a good habit.

Usually, there are logical divisions where you can stop and test the code before moving on. Once in a while, the particular code might be such that you have to code more than normal before testing, just because you can't easily test just part of it.

I've been programming for nearly 20 years and if I'm writing a program (C, C++, Java, shell script, whatever) to will read an input source, perform something on each line or word or whatever, I will always write the loop, the input statement and then print out the input just to ensure that I've got that part write before I start the code for processing the input.

I've worked with people who code the entire program before compiling it. Then when they run it and it crashes, they have no idea where the problem is. When I run a program and it crashes, I figure that the odds are it is in the area that I last changed, because I've tested (to the extent that I can) the previous code. That's not always true, but more often that not it is.

Programming OOP lends itself to my approach (some call it 'unit testing'). You should be testing each object thoroughly before moving to the next. I suggest building the class with data section and then compiling. Then start adding input and/or output methods one at a time and testing them.

Back in the days of typing lines on punch cards, submitting them to a processing center and then waiting an hour for results, it was a necessary evil to write larger chunks of code. Nowadays, you'll waste more time debugging large chunks of code than you'll spend compiling/testing code more often.

Oops, Guy beat me to the punch. He said the same thing as I, just much more succinctly.

Good points Don and Guy. My record is somewhere around 200 errors:-)
Also I'd like to point out that, as usual, I forgot that the less than sign is interpreted as a tag here. Sorry about that.
-SN

Thanks to everyone for all of the information. I've been meaning to learn about arrays for some time. The "one-dimensional" arrays don't seem to hard to grasp.But three-dimensional arrays? What the heck is that??? That sounds very frightening to me.

And to the people who recommended I compile small pieces of code as I go along, I think that is good advice as well. And I have actually tried it too. However, I found that I get a bunch of errors when I compile one thing at a time because something is always "missing". I don't know, something like "Argument X is defined but never used...". But you did recommend putting a loop in there to actually make the program more complete. (although you didn't quite use those words)I'm not quite sure what you mean, but if you'd like to elaborate on what you mean by using loops to test the code, I would appreciate it.

Also, I am starting to doubt I really understand what classes and objects really are, and what the difference between them is. Could someone please ask me some questions that would establish for certain, whether or not I understand what they really are?

Thanks

Jack

PS: As for the original project; I implemented the "interface" in the main function instead of treating it like another object and everything went okay.

I have to say that this is one of the most informative set of posts I've come across. Oh, and Jack, where was the long post? By my ridiculously verbose standards, that was pretty tame (but very informative ;)

Nice stuff already, so I'll talk objects. These days, as OOP has become so common, an "object" usually means an in-memory product of class "instantiation" at runtime. An object is essentially a strip of memory containing bits of data, like a plain C struct. Actually, C++ classes are based on C structs (pure data), and structs in C++ can also work as classes: definitions that essentially become data structs with functions specifically associated with them. The literature rarely seems to talk about this reality aspect, often only alluding to vague, intagible things (Booch would be proud).

Memory-wise, an object has a 'this' pointer (pointer to the object itself), variables declared by the class (including pointers to any other objects used), and so forth, but not the member functions (or statics). The class-defined functions are in memory separately, yet are available to all the class instances (objects) created. Thus, an object holds data specific to that particular instance of the class. With an array class (vector in C++), for example, you can create as many vector objects as you like, all with different data, but the same class functions get used for all. I won't cover virtuals and vtables here; that's too much now.

Programming-wise, classes are just a convenient format for grouping related data and functions together (encapsulation). Dealing with entire objects is often easier than keeping track of lots of variables spread all over the place. A class defines what variables will get lumped together into each object (data struct-ure) when created at runtime, as well as the functions to use with it. One deals with an object created from a class definition, as a whole, not as a group of individual data.

At compile-time, the compiler knows which functions are intended to work with certain data, and which ones aren't. Thus, data within class objects are usually "safer" (more isolated) than when variables are everywhere.

You will sometimes see objects refered to in the broader programming sense: any data allocated in memory, whether class-wrapped or not. That can confuse newer programmers. Sometimes I think things would be easier if class objects were routinely called instances. I hope I haven't been too theoretical (forgive me, Booch ;)

Cheers

Thanks for the help Jeff. I think I understood most of it(well, that is, almost everything but "Booch"). Do not worry about being too theoretical, because that's how I want any type of explanation to be. Well, perhaps a better term would be "precise". Analogies can be made, they just have to be accurate. Anyway, could you verify the following for me? Sometimes, I will attempt to say the same or similar thing, but in a different way):

1. An object, is just something built at runtime, to the specifications of its respective class.

2. An object is, essentially identical to its class, in the sense that it has all of the properties(data and functions) of its class.

3. Analogies, such as those relating classes , objects, and heirarchies, to real-world animal kingdom taxonomies are flawed for the following reason:
a)An instance can be made of any class in the OOP world. If X is a generic superset of Y; a valid instance can be derived from X, with all of the properties of X(but no more properties than X) despite the fact that X is generic. And of course, there can be instances of Y, the subset of X.

However, while in the real-world, an object of, for example, Canis familiaris(CF), domestic dog, is a valid object of class CF, having all the properties of CF, there cannot be an object derived soley(not from any subclass) from the superclass "mammal", with all of an no additional properties to "mammal", as the class mammal is an entirely abstract class.

(Although the above, to me, does appear to be an invalid analogy, there can be something similar that in my opinion, would be closer to a more accurate analogy. For example, the common evolutionary ancestor to all mammals, could be a valid superset of dogs, humans, cats, monkeys, mice, dolphins, and kangaroos, koalas, possums, and the platypus, echnida...etc. All sub classes of this common ancestor would inherit all the traits of that superclass. In this case, the superclass is a valid manifestation of the generic class "mammal". Nothing more than "mammal" nothing less. But then again, this analogy could also be flawed. Because many mammals did not inherit all of the features of our common ancestor. For example, some of the more primative reptilian features of this first mammal. But of course, we could mentally manipulate reality, so that this now, not-so-real, mammalian ancestor does not have any features uncommon to its decendants. But then again, the analogy is not exactly a real-world one. So I don't know. Someone, please help me with this.)

(Perhaps a more solid refutation to the typical heirarchial analogy would be this:)

The same can be said for many other abstract classes and entities in our world. They are entirely abstract and cannot manifest in reality, as opposed to a generic class in a computer program which can manifest into a valid, if very generic object. For example in our world, something cannot just be an object of the class "book" and nothing more. There is always something that can sub-divide any real particular book into a smaller class of "book". Is it an encyclopedia, a novel, a science book, a science book that is a text book, a science book published by so and so, is it a children's book, a blue book, a red book, ...?The "pure" superclass of book, can only exist in the realm of ideas.

I will stop here for now. But to explain why, I will use one more(not so serious and very corny) analogy inspired by some previous posts.
Imagine that my post is my source code. But it is incomplete source code. Some of my source code, may be wrong. So before I write much more, I need to see if what I have thus far will compile properly. In other words, I need to see if my points are correct before I make any more points that my be based on them. I guess I need all of you to debug this for me. And likely, my post is as stupid and faulty as my programs are.

Are we playing "Who can post the longest message"? :-) Sorry Jeff, I'm afraid your Jack has you beat:-)

I just wanted to point out a couple of things about two and three dimensional arrays:
a) I have only rarely (explicitly) used 2-d arrays, and have never (in a real application) used a 3-d array.
b) a 2-d array is simply an array of arrays, and a 3-d array is simply an array of arrays of arrays...therefore for 2-d you need three indexes, one for the "outside" arrays, another for the array at the first index, and for 3-d arrays you need three indexes.
c) Some people prefer to think of 2-d arrays as rectangular data structures,
------
|a b |
|c d |
|e f |
|g h |
|i j |
------
this would be an array of size 5 of arrays of size 2 (or the other way around) so to get the element f, you need to specify
array[4][1] (row and column)

People also like to think of 3-d arrays as cubic data structures, which are a bit harder to draw in ascii:-) Where you specify a row, a column, and a depth.

Hope this helps,
Jared
P.S. Sounds like Jack decided to dip into inheritance after all, huh?

I dont think i can beat Jacks post,
but ill give it a try!!

I think that everyone has explained Arrays
and OOP much better then i can, so ill talk
a little about programming-habits.

I cant belive that you can write an entire
program without de-bugging it before its
"done"!! I would go insane!! But it depends
ofcourse on how long the program your are codeing is. If its only 50-lines i could
write it in a chunk, but if its some 500+
program i dont see how thats even possible!!

When i started to program my first game, i
didnt think of every aspect of the code
before i started to program, i tougth
"well ill just have to solve the problems
when they come". And i got what ive asked for!! When i was done with the location system (i like to group all the function and
objects of an game-element into a system)
and started to make the item-system. I found
out that i needed to make some changes in
the location-system to make the item-system
work the way i wanted it to. And then when
i moved on to the script-system i found
that i needed to make changes to the previos
systems. And so it went to on....
And i used spagetti-programming then!
HORROR!!!!
I then realized that this isnt going to work.
So now i use a different strategy.
I think before i act!
I take a bunch of papers, a pencil and go
to bed 20:00!! But i dont fall asleep.
Instead, i think. I think and think and think. After a while of thinking, i write down my ideas on the papers. I then think of
how my ideas interact with other ideas, and
i write everything down on the papers.
This way i can get feed-back on my ideas
without sacreficeing valueble time on writting useless code. A thing that i discovered when i started to program is that
im very teoretical in my way of thinking.
When i first get an idea i think its great,
but when try to implemment i understand that
it neds alot of practical modifications.
And its MUCH easyer to see WHAT i need to
modify if its on paper.

This whole fenomena reminds me of the time i
used to make levels to Unreal Tournament.
I could get a great idea for an CTF-level,
and i started to built it at once. After
about 35-50% of the level was done, it wasnt
fun anymore and i started on something new!
I have about 15 unfinished levels on my
hard-drive that would be great if i just
would finish them!!! I then followed
Cliffy´s example, i put my idea on paper.
When i was finished with the papers, i began
building the level. It went really quickly,
but when i was 50% done, i discovered C++!!!
The level is still unfinished, and now im
making my own 3D-engine! I guess that when
im 50% done with it, ill start making my own
OS :-)

True enough, SN, though I have been holding back! =)

In answer to your questions, Jack:

I refered to Grady Booch in an attempt at humour; he is a major influence on modern OOP analysis. I used him to represent passion for the theoretical. Thus, my first reference nods to how he would be proud that much programming literature retains theoretical explanations. The second reference "appolologises" for explaining C++ objects concretely, thus breaking the mystique some newcomers feel regarding OO. I embrace the theoretical, yet also believe understanding actual implementation helps being more productive and less confused during actual use. No slights intended, just poor humour about the classic struggle between theory and practice.

1. Yes

2. Yes, although objects can have some actual values the class definition does not, making them unique. A class is a design specification for how to build objects/instances (and how the member functions will work). In general, one designs with classes, and does things with objects.

3. You have identified some of the discrepancies between hard-brass-science categorisation, and categorisation humans apply to the natural world (where things are not always clearly defined, but we try to make them that way).

If by "derived from X" in 3a), you meant "created from a definition of X", then actually 3a) may or may not be true (nevertheless, I agree that you correctly reasoned that OOP class-ification does not match natural classifications). That is, a base class in C++ (root class, basest superclass, etc.) does not have to be defined as abstract. An abstract root class (with pure virtuals) cannot be instantiated/created as an object, yet a concrete root class can, so it depends on how you look at things.

This requires opening padora's box a bit more to explain. OOP, which forms the basis for much design philosophy, hasn't historically embraced concrete root classes (I have seen heated arguments over this). A language or design is not considered truly OO unless it supports polymorphism and abstraction (which in C++ is implemented via vtables: unseen lists which allow different virtual functions to be called). An abstract base class is typically used to define a primary "interface" that descendents/inheritors/subclasses are to implement. In purer OO design circles, this is frequently assumed to be the case (3a's truth would not be questioned).

After OOP became popular, there was still interest in all-concrete classes (partly due increased popularity of templatised C++ classes). The rationale being that abstractness requires vtables (an efficiency hindrance) and implementation complexity, which in some cases is not necessary. For example, M$ embraced this with ATL for "fast and lightweight" components (though limited by being based on abstract COM, which is not inherently highest-performance). This approach is more accurately called Object-Based Programming (OBP), though the term is rarely used. C++ allows a mixture of both (as creator Bjarne Stroustrup intended), whereas some languages do not.

Anyway, all this makes talking about objects a bit messy, since OO in its strict sense does not cover all of class-oriented programming in everyday use. I think in terms of both, but some designers may not.

Conceptually, I suspect you will need to separate from the usual scientific paradigms, and tinker with classes more to see how the details work (as you said). It will get clearer, and I think for most of us, it is an individual journey to forge a mental understanding of it all. Somehow, nothing clarifies like doing. Oh, and although I could easily reply endlessly about evolution, I'll resist from making this the longest post ;).

Also, please note that the terms superclass and subclass can be confusing in programming. That is, a subclass in programming ironically contains a superset of the base/superclass. This is unlike usage in some fields. Thus, super* and sub* terminology sometimes conflicts between programming and other disciplines, and can cause misunderstanding depending on your point of view at the time. Curiously, back when I first got involved in programming, things were not so much a "science" as is considered today. Programming is still a relatively young field, a sort of force-fit of computer practice into a scientific model. We now have what we have, but hopefully it will become more consistent.

You might find it easier to create inheriting classes without abstraction (virtuals) initially, since inheritance is a big hurdle in itself. Virtuals are easy to implement after that. Inheritance can get pretty wild, and can definitely produce un-natural hierarchies.

Pardon the history junk, though sometimes it helps understand why some things are not always easy. No doubt, some observations will irritate a few, even when it's not an opinion; I have no interest in arguing. BTW, I can't consider thinking things out to be stupid, quite the opposite.

Cheers

Jeff, I took no offense whatsoever at your "Booch" reference. I was simply curious as to what you were talking about.

By the way,I was afraid my use of the term "superclass" and "subclass" might lead to some confusion. I am glad that you knew the context in which I using the terms and had a pretty good idea of my itent.And once I accidently used the term "superset" when I meant to say "superclass". Either way, it is confusing. Henceforth, I will attempt to use "parent class" and "child class" to designate inheritence as opposed to superclass and subclass.As you all know, C is often called a subset of C++, but C++ is also a "child-class" of C. So I certainly understand how this can be confusing.

Anyway, let me get this straight:
There are some classes which can not be instantised(hope I spelled that right)into objects? And these classes are entirely abstract and can only serve as a parent class? This OOP business seems to get more complex and foggy every day. I will be honest:
Thus far, I do not like it(OOP). Even with my limited experience in either the procedural or OOP paradigm, it seems like it is just making things harder. I admit, the prospect of using objects to model real life is very interesting. I thought OOP sounded really cool when I first heard about it. And I have been VERY excited about learning it. But I just feel overwhelmed. I don't think I will ever be able to understand what it is really about. Maybe my brain just is not cut out for it. I would really *like* to understand it, but I don't think I can.
Does someone have to be good at OOP to be a professional programmer? I don't know if I could ever learn this.

Also, this reminds me of a conversation I had with a professor recently. I called him and talked to him on the phone(we had talked before in person, though i am uncertain as to whether or not he remembered me). I tried to ask him some questions about OOP. He sounded like he was eating at the time, although he did not tell me to call back later or anything like that. Anyway, that may have been partially why he sounded agitated. He pretty much told me that I should learn to program before I learned OOP. I took it that he meant to imply OOP wasn't real programming. But at the time I wasn't sure what he meant so I didn't ask. He told me the only way to learn the right way to program was to learn assembler language; and went on to say that I should just take the classes offered by the school first. He went on to say that learning assembler is the only way to find out how the computer works, or something like that. He said if someone could learn assembler then everything after that is easy. I've heard the same thing said before from other people as well. I asked him something about what he thought of OOP and he confirmed my suspicions. He said something like it wasn't the proper way to program because of how it combines data and functions and treats them as one entity, or something like that. That isn't an exact quote and perhaps that is not what he meant at all. But he made one thing clear: He did not like OOP. ( I also got the impression he did not like me much either. I was surprised he acted kind of huffy though, because he seemed like a pretty nice guy when I talked to him before. Maybe he was just having a bad day. Or a really good meal.) All in all, it takes no genius to get the impression he thought the best way to program a computer was to model the problem in computer terms(the antithesis of OOP philosophy); hence his emphasis on learning assembler.

What do you guys think of what he said? Do you agree with is opinion? Is there some truth to what he said?

Do you mean seriosly that he sed to you that
you should FIRST learn assembler???
I havent programmed in assembler, but i have
spoken to people that have and they say that its very hard. What he sed about OOP is
his and only his opinion, not what everyone
thinks. Some like OOP, some dont.
I do agree with him on one point, learn
procedure programming before you start with
OOP. You have enough trouble with learning
the right syntax and stuff. When you feel
that you can make fun games/usefull programs
/whatever with standard procedure programming
only then you should start looking at OOP.
And ofcourse its hard, its always that in
the beginning. When you have learned
how use OOP to your advantege only THEN will you like it. Before that its hard to see what
so good with it, trust me!!
And it really enoys me when people say
"Ask your teacher for a good class" or
"Your school has a good compiler".
When i was 12 and started programming i
didnt have any teacher that wasnt a complete
morron when it came to computers, so i had
to learn everything the hard way.
The reason why i hate compiler developers
is that they assume that everyone is a
fully-learned computer-guru or has a thousand
computer teachers to speak to!!
If only they would spend 5 minutes on
writeing a good manual it would save many people days of pure frustration!!

I partly agree with your teacher in that although I thought I understood programming before, once I started assembly programming I looked at everything in a different light: Suddenly "efficiency" didn't mean doing things in fewer lines, and "write an algorithm" became a 40 hour assignment rather than a 40 minute assignment :-) However, I learned Java first, then assembly so I can't really say for certain whether it is a great advantage to learn assembly first. Either one will give you insights into the other. Don Arnett will probably have some good advice, since he has experience programming and teaching both.

As for your OOP woes, I think that, much like your logic question post a few weeks ago, you are second guessing yourself and convincing yourself that you understand much less than you really do. You dove into inheritance, abstract classes and the fallacies analogies between the real world and OOP before you even learned arrays...No wonder you're overwhelmed!!! If I had tried to learn programming in that order I'd be teaching 7th grade math by now! :-) (no offense to any math teachers out there...) I take partial responsibility for that, as I was the first to bring up inheritance.

Do your bankAccount class. Use it, understand everything about it, play with public and private members, and use the imperative paradigm you are familiar with to create the user interface in main. Use this step to understand instantiation.

THEN post back and ask about inheritance, and once you've learned inheritance learn abstraction (a close relative of inheritance).

THEN make a judgement on OOP. I realize that this argument is fallacious, but OOP is popular for a reason. It has nearly all the advantages of procedural programming and many advantages over other paradigms.

Can you be a professional programmer without learning OOP? It's possible, sure, but why limit yourself? Search for employers looking for java,c++, perl, or other OOP language programmers. Then search for employers looking for C,Prolog,Scheme, Lisp, FORTRAN, or assembly programmers. The numbers speak for themselves. Best of luck,
SN

Whiskey Bob,
Yes he seriously suggested learning assembler first. As do all of the professors at the school. The curriculum is set up that way. Like you, I heard how difficult and low-level assembley was, and I was surprised it was the first language introduced in the curriculum. I asked one professor, and he gave me, what I thought at the time, to be a pretty good explanation. He said(like the other professor) that learning assembly properly teaches how the computer works and how to program. I've also heard a prof tell me that it is a weed out sequence. He said that instead of putting the difficult weed-out courses late in the program, they put it at the beginning so students will know whether or not they are cut out for it before they invest to much time in the degree program. Which also makes sense to me.

SN,

"As for your OOP woes, I think that, much like your logic question post a few weeks ago, you are second guessing yourself and convincing yourself that you understand much less than you really do. "

You are more than likely right. In that my worrying about my understanding of those topics is probably because of my condition. However, that doesn't mean I actually understand those things. It just means I worry about it more than other people. I really do not believe I understand logic, or basic OOP principles. As for the logic stuff, you have no idea how much the following logical/boolean statments bother me:

1 OR 0=1
1 AND 0=0

I will state right off that I know how to represent these statements with logic gates, but in my opinion that doesn't count. So I have to refrain from using pictures to convince myself that I understand.
I see 1 AND 0, as true AND false. Most would agree with this. However, for this to have significance to me, I have to assign "names" to these values. So 1 AND 0, becomes A AND B.
A AND B, says "A is true and B is true". Then I assign the values to the respective names.

A AND B
1 0=false
therefore A AND B=false.

For "A AND B" to be true, both must be true.

Nevermind...because even this is starting to lose significance to me as well. This is so frustrating.