When I was first learning JAVA and still now when I read about any OO language, the author goes to great lengths to talk about :"blueprints" vs "the object" - in one text I see blueprints for a house and then an actual house. One author after explaining the blueprint/plan/object idea then refered to the latter as "a real live breathing object." I gasped.
A real live breathing object? really? Aren't we talking about computer storage here?
It took me a while to understand that a class was merely a user-defined data type which not only included the usual data variables, but functions that manipulated the data passed to these varibles. Simple. And they are functions/procedures, even if you re-define them as "methods".
And an "object" is nothing more than a variable whose "type" is the defined by the "class". For the life of me, I cannot understand the need for this type of re-defintion and elaborate explanation using houses, dogs, and bicycles. Are we all not well grounded in the concepts of data types, variables, functions/procedures, and computer storage and access?
I sort of understand your point, even if I don't agree.
An object is very powerfull in matter of variable manipulation. Far more than any other method.
Of course, using objects as variable containers is not the objective, even if it also happens.
It is, before all, a way of ordering your vars and methods in structured manner. It also allows you to enhance the security level of your code.
And, for me, it is a perfect way to build code in a modular inobstrusive manner.
It also brings a lot of ease when it comes to testing: you can test your object appart of the rest of the code.
OO programming hasen't been created for the fun, it's there to help, to enhance the programming possibilities.
Refering to objects as living entities is the way you see it once you fully grab the concept.
I agree 100% with your description and assessment of the value of this programming approach, and I agree that it is superior in many cases, especially with large projects which may involve many programmers and the need for future expansion.
My point was confusing the concept with "real live objects that are out there" - oop objects are not "out there", they are conceptual - it all takes place in the computer's memory. An object is not a living entity. It's not. It's a powerful variable of type "class" and the class defines what the variable [object] can access [do].
The symantics give it "life" - variables "access" - objects "do/behave". It's almost funny.
Hmmm ... one could argue that it's the functions [excuse, me - methods] that actually "do" the work. That would take us back to the value of ordinary procedural code. The actual algorithmic procedures that "do" the work are the same.
Sorry for being months late to the conversation. I wanted to say I wholeheartedly agree. I became more aware of this when I started reading about C++, and I got a more low-level insight into classes and objects. A class is virtually the same thing as a struct. Just a user-defined type that holds both data and pointers to functions that operate on that data. And an object nothing more than a variable of that user-defined type. I agree that the wholly different nomenclature is unnecessary, and perhaps even a detriment, because it makes OOP seem foreign to people who come from a procedural background.