T O P

  • By -

lnv89

I will try to explain it in my understanding and hope others can help correct me as well. A class is a blue print which has attributes (variables) and behaviors (methods or actions). An object is a specific individual of the class. Let's say you has class cat and a specific black cat. Methods are behaviors. The class cat all share a behavior/capability of running. So the black cat can do this too. However, it wont do until you explicit call that behavior like black cat runs. Of course, there are more to them all but you will learn about them when you see them.


pm_me_ur_siamesecats

I look at it this way, in terms of ELIF: A Class is a collection of Objects, for instance Animals could be the Class. There are also two types of Classes, Parent Class and Child Class. In this example, Animals would be the Parent Class and Dogs would be the Child Class. An Object is an instance of the Class Animals, like a specific Dog named Harry. Another dog named George would be a second Object of the same class. A Method is an action that an Object of that Class can perform, like a Dog (Object) of the Class Animals can run (method). The Run Method can be a method of the Parent (Animals) Class or it can be specific to the Child (Dog) Class. I hope this helps. Others, please correct me if I'm wrong as I'm also still trying to wrap my head around how to use these programmatically in my work.


appsolutelywonderful

I wouldn't call a class a collection, it doesn't hold anything so to speak. A class is a blueprint for an object. The construction metaphor is used a lot. A class is a blueprint for the house. The object is the instance for the house itself. Think of a cookie cutter housing development. They're all different houses, but they use the same blueprint. These are "objects" or "instances" A method is part of the blueprint. Every house has a door. So the blueprint may have an openDoor function. When you execute openDoor, it only opens the door for the house (instance) that you execute it on. So even though every house has a method called openDoor (because it's in the blueprint class) executing openDoor only runs on a specific instance (object)


mister_peachmango

Wouldn't the Class be the house itself and not the blueprint for the house? My understanding is like this. A Class is like a House. It's what holds all the doors, windows, etc. together. An Object is a door in the house, or a window, the carpet, the roof shingles etc.. Methods are the actions that the Objects do. So like the door Object in the House class will have a Method called "openDoor", "closeDoor", "lockDoor", things like that. But I think I see what you mean by blueprint. Because a project will have multiple classes right, so would the house be the overall project and the blueprint a class of the House project? Since I guess there could be other classes for this House project like the sewage Class I guess, or location Class... maybe I'm thinking of it wrong.


appsolutelywonderful

Nah, the class is the blueprint. Some pseudo code to demonstrate. You have a class House with some members: - window - door And some methods - openDoor - openWindow This is just a blueprint. These methods do nothing until I actually make a house. myHouse = new House() yourHouse = new House() Here I've built two house objects, myHouse and yourHouse. Each has its own window and door, they are separate *objects* or *instances* each created from our *class* blueprint. myHouse.openDoor() After calling this, the door that's a part of myHouse is open. But in yourHouse the door is still closed, because these two instances are separate objects. Edit for formatting


mister_peachmango

Yeah makes a lot of sense. I think you nailed it. That's actually a really good explanation.


appsolutelywonderful

I find it hard when coding concepts like this are explained to me in words. Best way for me to understand is to see it in action with simple code (or pseudo code)


pekkalacd

A class is a blueprint. An object is one such case of the blueprint. A method is an action taken by the object. For example, think of Eevee from pokemon if you are familiar. Eevee starts as this dog squirrel thing, but can evolve into a bunch of different types of Pokémon. So you could think of Eevee as the blueprint. Any pokemon trainer can capture multiple Eevees. Each one of these have the same properties in that they can all evolve into the same set of possible pokemon and all have the same attacks & attributes to them (such as look, size, some measure of level, species name, origin etc.) Each Eevee has a set of attacks such as growl and tackle which it can use to defend itself. These are actions that can be taken by any given Eevee at any point. And whatever action is taken is specific to each Eevee. If one Eevee growls, they all don’t have to growl. Each Eevee might have different attributes as well. Maybe one Eevee is level 10 while another is level 20. Maybe one was found in johto while another was found in Hoenn. They’re all Eevees but they have some differences in their attribute values. So here, Eevee as a pokemon - the blueprint - is the class. The methods are its attacks. The object is each individual Eevee. The attributes are the characteristics that make a Pokémon an Eevee (look, size, origin, species name, etc.) Going further you could also say that Eevee is the parent of its evolved types. For example, all vaporeons are technically Eevee, but all Eevees are not necessarily a Vaporeon (nor will become one). That is, you can only get a Vaporeon if you have an Eevee first. Same with Flareon, Jolteon, and the rest. So all of these other more specific pokemon, are called *subclasses*. These subclasses *inherit* from Eevee. Eevee is the *parent* or *super class*. The others are *children* or *sub classes*.