please dont curse me... every now and then i seem to really understand it, but i am a programmer from the 'good old days' and i need someone who can relate that programming to OOP so that i can understand better
Answer: (although please note i'm a little biased <grin>)...
Yes, I have gone out of my way to think very deeply about the ways of teaching OOP concepts so people can understand it. If you have questions about it in the future, please contact me at Briano2u@aol.com. (Sorry I am late coming to this thread... some family emergencies got in the way.)
The question of how to teach OOP concepts has been something that has deeply occupied me for many, many years. I love the whole writing challenge. Unfortunately, the field of writing about object orientation has attracted florid, elaborate analogies, dry technical descriptions that are hard to follow, or puffed-up promises that I feel are not justified. So for this edition, I scaled some of the rhetoric down and tried to emphasize what the practical, demonstrated advantages and concepts are.
One thing I do is not to introduce too much object orientation right away, believing that new programmers have enough to worry about just learning the basic syntax of variables, functions, control structures, and so on. However, in my book, the built-in objects "cin" and "cout" form the basic of input/output from the beginning, and I see this as a springboard to understanding other objects later on. So of course, all input/output in the book utilizes these built in objects for I/O, along with file objects.
To help you just a little, consider that object orientation is a way of letting the programmer customize his or her own data types to the maximum extent. One of the major goals of the book is to show, for example, that in addition to the integer and floating-point built-in data types, you can provide your own custom data types (such as fractions and points) and then define what it means to add, subtract, and multiply them.
But object orientation is more than that. It is also a way of organizing programs. An object (and other objects of the same type, called classes) is a data item that "knows" how to repond to functions and/or operators.
Why is this useful?
That's a question I take on in the book at some length, but the basic answer is this: as programs get larger and larger, and data interactions get more complex, it can be very helpful to organize programs into units (called classes and objects) in which closely related data and function code are kept together. There is little "magic" here... you still have the hard work of programming to do, but for complex programs it is a superior kind of organization.
My challenge has always been to show how smaller programs can benefit from object orientation. This I've tried very hard to do in my book... I believe, once again, the answer is to be found in the use of simple I/O objects and in taking advantage of the Standard Template Library (STL), which can save you a great deal of work -- but requires that you understand the class/object syntax!