OOP terminology

@Eugene Dakin : Just one addition because I am a bit confused by your house and home comparison.
Object and instance are just two different viewpoints onto the same thing. While object simply says “not a common datatype”, instance always references the class it stems from. You would not talk of an instance but of an instance of a certain class. You could talk of an object without referencing a certain class.
Basically the terms are interchangeable but the context may favour one of them.

[quote=469548:@Eugene Dakin]It seems like there is no right or wrong answer to this question, as there are many valid ways of describing this.

Thanks for the helpful posts everyone.[/quote]

Actually it is a right answer and lots of wrong answers.

Maybe this post could lead to a better understanding: https://forum.xojo.com/54352-about-weakrefs/

Intersting… I think of an object and instance being the same thing but just with aa difference is specificity…

The class is the template but an object is a concrete item, in other word and instance of the the class object…

So I see object being when when yo are talking about an instance of ANY class and instance when you are speaking about an object of a specific class.

  • karen

This page has a nice reading of how one would explain objects, instances, classes etc

https://alfredjava.wordpress.com/2008/07/08/class-vs-object-vs-instance/

Applies to all OOP programming.
It would be useful to have a Xojo engineer creating a blog post about this.

I see it as a class being a template or blueprint. An Instance is an empty object, using the “New” keyword. While an object is a filled, usable instance having it’s properties set.

there is also a special case without the new keyword, in xojo it would be a shared property.
Person.Age = 48

For those who still think and program procedural, I would recommend watching some good videos like “Programming Foundations: Object-Oriented Design” from Barron and Olivia Stone on LinkedIn Learning. Not a new video, but OO en UML principles are still valid of course.
You can practice the lessons learned right away with Xojo.

Learning Objectives:
Object-oriented basics: objects, classes, and more
Encapsulation
Inheritance
Defining requirements
Identifying use cases, actors, and scenarios
Domain modeling
Identifying class responsibilities and relationships
Creating class diagrams
Using abstract classes
Working with inheritance
Developing software with object-oriented design principles

Being of the procedural thinking type, I cannot object to you recommending more class work in this instance.

Robert, you are absolutely correct. The definition of an “object” in OOP and anything that can be acted on, and a template, or class, can certainly be acted on. It can be created, changed and deleted, so yes, a class is an object. To say a class only becomes an object when it is instantiated is wrong. I do understand the point that Tim was trying to make and the soft differentiation between a class and an object since a class, once created, is typically static whereas the instance of that class, or object as defined by Tim, can be modified by setting the properties and calling the methods defined within the class.

My burning question is what problem did you have with the old Bob that you needed him to be a New Person? :slight_smile:

I laughed so hard that I spit my coffee when I read your comment this morning. Well done :slight_smile:

There is even a series about Bob: https://www.amazon.com/We-Are-Legion-Bob-Bobiverse/dp/B01L082SCI

[code]// Run method to clean the table and mug
oTable.Clean
oMug.Empty
oMug.Wash

// Get new coffee and refill the mug
dim oCoffee as new Coffee
oCoffee.choice = cStrong
oCoffee.make(0.5) // 0.5 liter
oMug.Fillup(oCoffee)[/code]

Oooohhhh…I hadn’t heard of that one. I’ll have to add that to my reading list.

[quote=469620:@Joost Rongen]// Run method to clean the table and mug
oTable.Clean
oMug.Empty
oMug.Wash

// Get new coffee and refill the mug
dim oCoffee as new Coffee
oCoffee.choice = cStrong
oCoffee.make(0.5) // 0.5 liter
oMug.Fillup(oCoffee)[/quote]

If you don’t object, I thinking that a more appropriate language for this class of problem, at least in this instance, would be …
(wait for it…)
Java

Having read all three books in the series, I can heartily recommend them. Bob in this case is an artificial intelligence with a soul and a great sense of humor. Science fiction at its best.

Dog, Human are (abstract) classes, describing the properties and functions of their respective entities.

Fido and Bob are instances of their respective classes.

Fido and Bob are objects (I.e. instances of some class)

I read this series as well. Quite entertaining. The author obviously knows a thing or two about software development (being a developer himself), which made it more interesting for me.

But now we’re getting WAY off-topic, so here’s a nice & concise break-down on-topic from @Norman Palardy’s blog Classes, Instances and Objects.

Classes are DNA coding. If it is human DNA, it has the information to create a new human. cat DNA can make cats.
Objects are humans (Mankind). They are the manifestation of their class
Instances are individuals. (Bob)

[quote]// Grammar is a little screwy because Bob is a human not a humanDNA But humans are abstractions.
// But we can live with that. When Perlman tried to improve the grammar with v. 2 the Xojosphere jumped down his throat
Var Bob As New humanDNA // So now Bob is a human but we don’t know anything about him

// Now we will flesh him out (so to speak).
Bob.age = 64
Bob.height = 6.2 feet
Bob.appelation = “Robert”

// Now Bob has become an instance.[/quote]

Bob can do things. He can interact with other instances (his car, his cat, and with his friend Susan).
Bob is a human object. We can talk about humans in general over cocktails. But in our code, we talk about Bob (or Susan). Bob does this and that. The general characteristics of Bob and Susan are captured by the range of characteristics of humans. Human don’t fly for example.

But it is entirely possible that Susan could perform some job that Bob could not. When you (the coder) want a task done you have to decide whether Bob or Susan is going to do it and you have to make sure that that individual is empowered to do it.

You can’t ask the DNA to do it. DNA can only make another human. That is all it is good for. You can’t ask human to do it. Humans are just a concept. “Somebody should do something about the state of education in America” That is not how code works.

Classes have names in our code. Instances have names in our code. Objects, no.

Fantastically clear and detailed explanation Robert. Best description I’ve seen yet.

[quote=470020:@Robert Livingston]Classes are DNA coding. If it is human DNA, it has the information to create a new human. cat DNA can make cats.
Objects are humans (Mankind). They are the manifestation of their class
Instances are individuals. (Bob)

Bob can do things. He can interact with other instances (his car, his cat, and with his friend Susan).
Bob is a human object. We can talk about humans in general over cocktails. But in our code, we talk about Bob (or Susan). Bob does this and that. The general characteristics of Bob and Susan are captured by the range of characteristics of humans. Human don’t fly for example.

But it is entirely possible that Susan could perform some job that Bob could not. When you (the coder) want a task done you have to decide whether Bob or Susan is going to do it and you have to make sure that that individual is empowered to do it.

You can’t ask the DNA to do it. DNA can only make another human. That is all it is good for. You can’t ask human to do it. Humans are just a concept. “Somebody should do something about the state of education in America” That is not how code works.

Classes have names in our code. Instances have names in our code. Objects, no.[/quote]

Just to be clear if Bob and Susan are instances of the same class, in your code, then they have identical abilities (unlike humans where EVERY human isa new CLASS type - because we’re all unique)

EVERY instance of the same class TYPE has the exact same abilities (methods) that can be relied on