But they can have properties that limit or extend (relatively) their methods. Humans might have the run method but we are not all Usain Bolt.
Wich still supports what Normans said. For explaining a suspected difference between instance and object, your example does not fit well because you are basically saying that you need an instance of the fitting subclass for a task.
Sure they do. Any instance of a class is also an object. As I said earlier, to call something an instance (of) is just another view onto the same thing. Object is a generality. To extend Roberts example: Any being is an object. Any being is also an instance of its species: Mammal, reptile And of course at the same time an instance of its subspecies: dog, cat, human And of its sub-sub-species and so on, down to its family.
In terms of code, we mostly view objects from the instance viewpoint: We want to handle a certain class. Because, as Robert stated, not every class matches every purpose. So we ask for certain class instances, like a DateTime, a sound, a picture
But technically, each instance of each class we handle is at the same time an object. Its just the viewpoint we change.
Only rarely like when we use variants , we use the object viewpoint in code ourselves. But in most of the cases we will then still change the viewpoint and ask for the object class when we process the input.
The object viewpoint states (in this example) solely that a being exists. Viewing an object as an instance reveals its class, because by syntax instance cannot stand alone in a sentence. It is always an instance of a class. You dont say “you need to create an object of MainWindow”. But on a more general viewpoint that instance of MainWindow is still an object. But you have to get closer to examine it and view it as an instance of its class to know more about it. In most of the cases.
EDIT: Like you would usually only say “That is the son” if the context is known (Using FamilySmith). The way more common sentence would be “That is the son of Mr & Mrs Smith.”
EDIT: Under this viewpoint of course one has to agree with Robert again: In Xojo, an object does not have a name if viewed as an object itself. In many other languages, every object will at least have its individual handle.
And in some others, everything is an object.
Properties are data - it might result in differetn behaviour IF your code relies on the data to determine how to process that data
But the methods and events (the actual code) are the same across all instances
I guess we are needed for the slowmotion pictures, Bolt’s picture were allways unsharp.
Not a scientist view:
Doesn’t the whole thing fall apart where to change an organism’s (instance) properties you have to change the DNA? My eyes are blue because my DNA says so. That’s not how classes work, classes say my eyes can have a color.
Humans & DNA are not a great metaphor because they don’t actually behave the same as classes & instances.
Classes are more like a template for creating new items of that type. And all items of that type may have different data, but they will all have the same set of method, events, properties, etc etc. In that regard they are identical EXCEPT for the data they contain.
In the case of something manufactured though it fits better.
Chevy makes a wide variety of vehicles.
Each type of vehicle is a specific CLASS - a Silverado, Colorado, etc.
And every last one would, without customization be “identical” - flat grey with a specific engine type etc.
Customization can be thought of as creating a “subclass” of the general type - a Silverado with a bigger engine is still a Silverado (the more general class) but with a few special tweaks &customizations.
And every other Silverado configured exactly that same way would share those same characteristics. They would all be IDENTICAL - you might think of their color as “data” - mechanically they should be identical (in theory but car owners know this isnt true)
And all of the customized Silverados would share some characteristics with the more general generic Silverado and some between them that are different from the original Silverado
And each of those Silverados, as they rolled off the production line, IS one instance (mine, georges, freds, etc)
And they are all “vehicles” (objects) along with all the vehicles made by Ford, Fiat/Chrysler, Toyota ,etc
Humans dont work that way at all
We mostly share some characteristics in terms of how we appear - 2 legs 2 arms upright etc.
Except for when we dont because of genetic variation - and thats where the metaphor fails.
Humans arent carbon copies and cloning isnt quite the right notion for how classes work.
[quote=470344:@Tim Parnell]Not a scientist view:
Doesn’t the whole thing fall apart where to change an organism’s (instance) properties you have to change the DNA? My eyes are blue because my DNA says so. That’s not how classes work, classes say my eyes can have a color.[/quote]
It is just a instance with read only properties.
[quote]Customization can be thought of as creating a “subclass” of the general type - a Silverado with a bigger engine is still a Silverado (the more general class) but with a few special tweaks &customizations.
And every other Silverado configured exactly that same way would share those same characteristics. They would all be IDENTICAL - you might think of their color as “data” - mechanically they should be identical (in theory but car owners know this is’nt true)[/quote]
I would contend that customization could be thought of in two ways. You like to think of it as a subclass if a Silverado has a bigger engine.
You have decided to emphasize that (in contrast) different colors are “mere” data. I assume that you mean colors might be a property.
But I think that you could have a property (engine size) that would differentiate two Silverados even though they were the same class. That property, in turn, might determine the top speed and miles/per gallon. It would not be as “trivial” as color.
It seems to me that you could approach the problem of these two types of Silverado in different ways.
- Making a subclass
- Assigning different properties to members of the same class
I can imagine situations in the life of a programmer that one or the other approach was simpler or more comfortable. My sense is that I tend to work more with properties and Norman with subclasses.
For those watching from afar, I might note that I am what has been called a “citizen programmer” and Norman is a “professional programmer”.
Well, when an example designed to help clarify a situation breeds confusion, it is hard to conclude that it is anything but a bad example. Mea culpa.
But just to be argumentative, eye color might be genetically determined but there are many properties of a human (knowledge, skills, relationships) that are not.
In some sense, any class, even one with NO assigned properties have what in the English language might be called properties. The human class might be considered to have four limbs and two eyes even though there is no property that has been created to describe this. All instances of the class are assumed to be identical in this regard.
When a property is assigned by a programmer to a class it implies that there is a variation amongst the instances of a class in this regard. And there is no reason for the programmer to bother if that difference does not make any difference in how the program works.
Eye color might not have any significance in how the program works so I can dismiss it. But I think that Tim and Norman are making a valid point of sorts. Until properties get assigned (if they do at all) classes are IDENTICAL and humans are not. I can argue that my program is not interested in eye color so bringing it up is just to throw dust in the air. But my analogy does fail to capture the fact instances of a class are strictly IDENTICAL if that class does not define any properties or if the two instances have the same values of whatever properties are defined. Humans are not identical.
But, in my example, I was implying that humanDNA is identical. Like it was cloned humanDNA. Like when someone uses the example of a blueprint as defining a class we understand that it is the same blueprint. My implicit assumption was that it was the same humanDNA.
But anyway it threw some people off track
[quote=470561:@Robert Livingston]I would contend that customization could be thought of in two ways. You like to think of it as a subclass if a Silverado has a bigger engine.
You have decided to emphasize that (in contrast) different colors are “mere” data. I assume that you mean colors might be a property.
But I think that you could have a property (engine size) that would differentiate two Silverados even though they were the same class. That property, in turn, might determine the top speed and miles/per gallon. It would not be as “trivial” as color.
[/quote]
You most definitely could make engine size just a property - depending on use case thats more likely to be the correct approach
[quote=470562:@Robert Livingston]But my analogy does fail to capture the fact instances of a class are strictly IDENTICAL if that class does not define any properties or if the two instances have the same values of whatever properties are defined. Humans are not identical.
[/quote]
The classes are “identical” in that they have the same set of properties but the values in those properties vary (humans have 2 eyes - their eye color varies)
They have the same events and methods
The class is a template for every instance. The values in each instance vary.
It seems inevitable that every OOP discussion ends up poking holes in analogies. Similar to looking at the photo of a cat and complaining you can not hear it purr (!)
What gets lost in these discussions is the utility of OOP. OOP is human utility and a design concept, intended to make a complex finite state machine appear a little less ‘alien’ to human programmers. Keep in mind that the machine is fundamentally sequential and source codes compile down to machine instructions that resemble first generation BASIC “spaghetti.” The logical grouping of data and executable instructions that represents a software object in source, is blown away by a compiler.
I see little point over-thinking a source code paradigm.
[quote]But my analogy does fail to capture the fact instances of a class are strictly IDENTICAL if that class does not define any properties or if the two instances have the same values of whatever properties are defined.[/quote]Strictly speaking, just no! Uniqueness is an attribute of the word “instance.” All instances are unique, just as identical twins and similar cars are in fact unique.
An ‘instance’ is a physical presence. However alike identical twins might appear, they can not occupy the exact same physical space, hence we can deduce that each twin must be a unique instance. Instances of software objects are no exception. The physical presence of a software object is the electrical representation in memory at run-time. No two instances of a software object can occupy the exact same address space, therefore every instance of a software object IS unique.
For what it’s worth, this is how I understand the terms.
Object (software) - A ‘vague’ design concept - often scribbled vaguely on a white-board. Created when a developer envisages entity X needing attribute Y and behaviour Z. In OOP parlance ‘Object’ refers to the logical grouping of data with the executable instructions that act on it - IN SOURCE.
Class - A ‘concrete’ type definition statement, useful for grouping data (properties) and executable instructions (methods) together as a logically combined entity - IN SOURCE. Also known as, “a struct on steroids.” At run-time, data must be located in RAM, while executable instructions may be blown onto a physically separate PROM or located in a read only address space. After compilation a Class more closely resembles a bunch of functions and a struct containing pointers to them.
Instance - A software object’s physical presence in memory at run-time. For practical purposes we can take ‘memory’ to mean RAM specifically. An instance is created when RAM is allocated to hold an object’s data, (a struct remember,) and destroyed when that RAM is released causing the contents to be invalidated.
To demonstrate the difference between a type definition statement and an instance, pick up an English Dictionary. The pages of an English Dictionary are full of type definition statements. For example: “Truck - a large road vehicle that is used for transporting large amounts of goods.” What you will not find in an English Dictionary is an instance of a truck - it will not fit between the pages.
The English language allows the terms object, class, instance to be used interchangeably. A computer’s memory is not so malleable. I find it helps me to maintain a clear distinction along the lines of design, implementation and (physical) behaviour at run-time. We think of objects, write classes, construct instances.
That is true.
Dad was blond/blue eyes; a nephew is brown and had a daughter with a brown woman, the daughter is blond with blue eyes ! So eyes color is coded in 64 Bits 