OOP Classes, Why are they called Classes?

[SteveWasiura]

I've read a bunch of stuff on wikipedia but I can't understand why they are called Classes.

 

Where did Classes come from or originate, what was the creators intention by calling it a class?

 

I can understand "prototype", it's like the first attempt at building something. But I don't udnerstand why it's refered to as a "Class".

 

Is it called a class because it's a collection of things related to one concept, like students in a class about math?

 

Or is it a classification of something that attempts to find it's place in a mess of many "things"?

[falkencreative]

I'm actually not sure, and I don't believe I was ever told what it means either. I usually think of it in two ways though:

 

-- "class" short for "classification", same way that birds and animals are classified into groups via family, genus, species, etc.

-- "class" in the sense that a history class should create students who are knowledgeable about history, so a PHP class creates objects that are knowledgeable about their particular subject. (Rough analogy, I know.)

[SteveWasiura]

I found this in the php manual comments section. http://www.php.net/manual/en/language.oop5.basic.php#86235

 

use classes to "organize and deal with like-minded data". Here's what I mean by "organizing like-minded data". First, start with unorganized data.

 

<?php

$customer_name;

$item_name;

$item_price;

$customer_address;

$item_qty;

$item_total;

?>

 

Now to organize the data into PHP classes:

 

<?php

class Customer {

$name; // same as $customer_name

$address; // same as $customer_address

}

 

class Item {

$name; // same as $item_name

$price; // same as $item_price

$qty; // same as $item_qty

$total; // same as $item_total

}

?>

 

 

 

So yes, I think maybe the reason it is named Class, is because it organizes things, like classification does.

[kraxzy]

It means exactly what its name stands for.

 

If I say to you like this, how would you classify this batch of code? Well you would look at the behavior of the code, and what another batch of code would see and be able to get to if using it. And you conclude: (for example) Aha! it has all the functionality and behavior needed to classify it as an account, or vehicle, or human or maybe something else. Thus it must be that thing!

 

If you can classify something as X, it is of class X.

I can classify you as a human thus you are of class human.

 

And this is the key element of OOP, encapsulation of code, NOTE code that describes and adds functionality that object should have to be classed as such.

 

So if you for example want to create an object with the functionality of a airplane, and you end up with something more resembling a bicycle, then you have failed with the classification.

 

You can then create your own classes, let say you want to call everything that has this behavior and this functionality for a BUMP, then you can write a interface describing this new object and what is needed and expected from such a class of objects.

 

Once you get into the OOP mindset, it becomes almost strange to think about it in a procedural matter.

[SteveWasiura]

I thought I had too much to drink last night, because at first glance I could not understand your posting. But I let it sink in, and now I think I've got it.

 

You have to be able to describe something, so that you can classify it. I think a classification is basically a set of statements that describe something, i.e. a human would be described by it's properties, etc.

 

So when we create something that will become an object in our code, we have a bunch of statements that describe it's properties, and we also have a bunch of methods that do things with the object, i.e. set a value of the object (i.e. it's name, size), get values, etc.

 

So by putting all this together (encapsulating) into a series of statements (variables and functions), we have created a classification that describes the object that will be created when using this bundule of code.

 

So I guess that is why it is refered to as a class, short for classification.

it is a group of statements that describe an object.

[administrator]

Hi,

 

I just caught this thread ... yep, think CLASS as in CLASSIFY or CLASSIFYING.

 

Remember that when you write the code for your class, it is technically not an object, only a description of an object type or in other words: class. Like an SUV is a class of vehicle.

 

The act of instantiating/created the object at runtime (runtime = when the code is actually running) is when the class actually generates an object.

 

Stefan

[LSW]

It is really not so strange, just look at the real world:

• The Navy uses it all the time: Both as classes of warships, Aircraft Carriers, submarines, cruisers etc, As well as by the first ship of a class, Atula class submarines, Sea Wolf Class attack submarines, Wasp Class LHD.
• Mercedes uses classes like the top of the line C Class Mercedes.
• Weather like a Class 5 of F5 tornado.

Just to name a few. It is a form of description of common traits.

[kraxzy]

I thought I had too much to drink last night, because at first glance I could not understand your posting. But I let it sink in, and now I think I've got it.

 

You have to be able to describe something, so that you can classify it. I think a classification is basically a set of statements that describe something, i.e. a human would be described by it's properties, etc.

 

So when we create something that will become an object in our code, we have a bunch of statements that describe it's properties, and we also have a bunch of methods that do things with the object, i.e. set a value of the object (i.e. it's name, size), get values, etc.

 

So by putting all this together (encapsulating) into a series of statements (variables and functions), we have created a classification that describes the object that will be created when using this bundule of code.

 

So I guess that is why it is refered to as a class, short for classification.

it is a group of statements that describe an object.

 

 

Yes, in OOP circumstances there are two key concepts, behaviour and properties of the object.

The properties in php would be things as the variables, constants etc, and the behavior would be the way it acts through the interface available with which you communicate with the object ( in short the functions available).

 

Also key is to really grasp the distinction between a class and an object, as these are not the same, a little deeper knowledge here is neccessary in order to really be able to write good code.

 

Object is an instance of a class, which could be described as all unique properties and behavior to that individual set living in the memory, whereas the class bound properties and behavior would point to the same areas in the memory always during the run, thus are not a part of the object.

 

In short this means that a part of an object are properties that change (aka variables, and functions using these) they are unique and have unique storing adresses in the memory, thus you have to create an instance of the class in order to get to use these properties and behavior. each instance of the object becomes an independed identity in memory.

 

Wheras constants, static variables and functions, are class bound, and not object bound as they never change they are by nature constant throughout the code run. Making these values unique would be a waste of resouces.

So they are only a part of the class and not of the object. They are also auto loaded into memory thus making them available without creating instances of objects.

 

 

So to remember; properties, behavior, the difference between a class and an object.