macOS Page 25, Objects

[larswik]

The book uses examples and says think of objects as things like a CAR. It is saying that CAR is the name of the CLASS from which I create an INSTANCE of that car.

Now from what I understand an INSTANCE is like a copy of the original that you work with, correct? Am I to assume that I work with instances because I can not change the original class or it keeps me from screwing it up?

Thanks,

-Lars

 

[Cromulent]

The book uses examples and says think of objects as things like a CAR. It is saying that CAR is the name of the CLASS from which I create an INSTANCE of that car.

Now from what I understand an INSTANCE is like a copy of the original that you work with, correct? Am I to assume that I work with instances because I can not change the original class or it keeps me from screwing it up?

Thanks,

-Lars

If you have class car then an instance of that class would be a Ford Focus or Mazda MX5. The class is something that describes a group of items and an instance is a specific example of that class.

A class is there to describe general rules for that group. So in the car example it would say they had 4 wheels, a steering wheel etc.

 

[larswik]

I understand. On the next page he did use that example with wheels, washing it and so on.

His example was Class Car and my instance was MY CAR and the instance method was DRIVE, WASH IT, FILL GAS and so on. He said finding out how many different cars the manufacture has with be a Class method

That was a fast response!

Thanks,

-Lars

 

[Cromulent]

I understand. On the next page he did use that example with wheels, washing it and so on.

His example was Class Car and my instance was MY CAR and the instance method was DRIVE, WASH IT, FILL GAS and so on. He said finding out how many different cars the manufacture has with be a Class method

That was a fast response!

Thanks,

-Lars

Also it is important to remember that instances inherit the values of the class that they are a member of. So you should in theory only have to specify the generalities in one class only. Design seems to be the number one most important factor in OOP (much more so than in procedural programming although it is obviously important there).

I really need to pull my finger out and do some OOP stuff.

 

[cmaier]

Think of the class like a blueprint for a car. The blueprint isn't useful for anything other than for churning out cars.

You can look at the blueprint and say, hey, when that's built, here's how I'll wash it, and here's how i'll steer it, and it will have properties like color and speed, etc. But until you actually get through the factory, there are no cars.

Or something

Of course, "class methods" break this idea a little bit, but not entirely. Class methods are simply things that all cars share. That is to say, there is only a single instance of the method amongst all the cars. Like no matter how many cars you have side-by-side, when they tune their radios to 98.6, they all are forced to suffer and listen to the same class radio station.

Class methods are not used as often as programming books suggest. Some places I've used them:

constants. For example, I might define a class called MyColor. Then I might have class functions:

MyColor.red()
MyColor.blue()
MyColor.green()
etc.

"red" means the same thing always, so if it's a complex structure I only need to allocate memory for it once.

 

[larswik]

Thanks, the book is starting to go in depth about this to give me a clear understanding.

-Lars