What is the difference between a namespace, a class, an object and an instance?

Question

I'm reading Heads First C# (it's very interesting and user-friendly), but I wondered if anyone had a useful metaphor for describing how Name spaces, Classes, methods, properties, etc. all 'fit together'?

Is Class a Parent and a Method a child, etc. Or is it more complicated?

Could a Name Space be a house, and a Class be a room (Bathroom) and a method be what can be done in that room (wash, etc.) and the properties be what can be done when doing that activity, use soap, hot water...

...I'll get my coat.

Answer 1

Think of classes as descriptions of objects and methods as actions those object can perform.

For example, I design a new car. The plans or blueprints (classes) for that car are what is used to create actual, physicial cars (objects). Those plans indicate that the car should have a functional horn. Therefore, I have designed honking functionality (a method) into the car. Those plans also indicate that the car have four wheels. Wheels would be a property of the car with an instantiated (assigned to the property when the object is created) value of 4. Color would be another possible property. Properties describe object qualities or characteristics (color, height, width, etc.).

Now, I work for Toyota (not really, but bear with me). Toyota would be the namespace that includes my car blueprint. Since Ford, GM, etc. can all have their very own car designs (classes) as well with the very same names (car) and methods (honk), the namespaces of Toyota, Ford and GM keep those blueprints (classes) separate and distinct, as you can have multiple versions of classes and methods with the same name in an application when they have different namespaces.

Hope that helps.

Answer 2

I would say:

• Namespace: A category or brand of cars. Note that the brand really doesn't have to dictate how the car is built. You can't say a Honda always have four doors, or that it always has 4wd. Such specifics is up to the class to dictate. Rich.Carpenter's post explains the purpose of namespaces very good.

• Class: Blueprint for how to build a specific car.

• Object: An actual car (instance) created from the car blueprint (the class)

• Method: Something a user of the car can make it do. Start(), IncreaseThrottle(), Break(), OpenDoor() etc.

• Property: Attributes, information and building blocks which the car contains. E.g. Total running miles, color, steering wheel dimension, stereo system etc etc.

Some concepts which could seem more advanced to you. Maybe overkill right now, but read it if you're interested:

• Inheritance: When a class is based on another class and adds some more specific details. A line of inheritance usually goes from the most common and general aspect, all the way down to a point where it makes no more sense to be more specific. Example of this in the context of animals: Animal->Mamal->Rodent->Rat->RattusNorvegicus

• Aggregates: Properties that "builds" the object. E.g. "This car is an aggregation of four wheels, a chassi, an engine, etc".

• Attribute: Properties that describe the object, usually not part of its physical construction. E.g. Color, top speed, engine volume etc.

• Encapsulation: The concept of concealing certain properties from the user, or to protect certain properties from being used incorrectly (and thereby damaging the object). E.g. You don't expose the gear-property of a car class to be altered freely. You encapsulate it and make sure Clutch() is called before SetGear().

• Overriding: If a class inherits from another class, it also inherits methods from that class. Overriding is basically when the inheriting class replaces the implementation of such a method with its own required behaviour. Example of usage in next point.

• Polymorphism: A difficult concept to grasp until you start using it practically. It means referring to a very specific kind of object, by using a generic reference which allows you to ignore the specific type (when you don't need to know it). E.g. If you wan't to "read" the license plate number property of every vehicle in a parking lot, you don't really care what the brand is, or even if it's a trailer or motorcycle or whatever. To be able to do this, we make sure the license plate number is a property in the most general class in the inheritance line (probably the Vehicle class). So you only have to deal with all the objects in a list by referring to them as Vehicles and then call Vehicle::GetLicensePlateNumber(). Any vehicle requiring some special handling to retrieve the number can implement this behaviour by overriding the method and make it behave as required. So a wide range of object types can be used as if they were of the same type, but can behave differently.

Answer 3

Classes are generally used to represent some kind of object. It could resemble a physical object like an invoice, but it could also be something more abstract.

Animals are sometimes used as examples for classes, because we are familiar with how animals work. So, let's use some animals:

Classes could be a kind of animal, like Cat and Dog. When you create an instance of a class it becomes a specific object, like Fido the dog.

Namespaces are used to group classes logically, so the Cat and Dog classes could be placed in the namespace Animals.Pets. Although namespaces are hierarchical, that doesn't make the classes in them hierarchical. They are just different groups, so the classes in the Animals namespace are not automatically parents to the classes in the Animals.Pets namespace.

Methods is something that the objects do, like Eat() and Sleep().

Properties is something that describes an aspect of an object, like NumberOfLegs and IsSleeping.

Answer 4

Hi,

I would say your classes might be job positions, performing different actions (the actions being methods, in other words). You may have various individual people performing the actions (the various instances of the objects).

These collections of job positions would reside in a department. Finance has its jobs/classes (accountants, book-keepers..) but they would need to work with Sales, who have their own types of jobs/classes.

In this sense, the various departments are the namespaces. people working in Sales need to eventually work with Finance. Multiple departments (or namespaces) are working together to achieve a goal.

Now these departments may be part of a company; that company would be the root namespace of all these departments. And in such a manner, namespaces can exist and be nested together.

In a nutshell, namespaces pretty much segregate responsibilities.

Imagine multiple companies working together (Microsoft .net namespaces working with your own namespace) and you get the greater picture.

Answer 5

in one sentence:

an Object is an Instance of a Class

Answer 6

An object can be an instance of a class?

Answer 7

5 seconds on Google:

http://www.dotnetspider.com/forum/182144-whats-difference-between-class-object-interface-instance.aspx

Answer 8

A class defines what an object looks like - what data it contains, what methods it has, and what other classes its related to.

An instance is a single created entity of that class - its an object created by using the class definition as a reference.

Answer 9

A class is a type of object. For example, you can have as many objects of one class as you want.

An instance is an object, and sometimes the two terms are used interchangeably, because in many languages, all objects are also instances of a class. People use the word 'instance' to make it explicit that they are not talking about a class, but an object of that class.

Answer 10

Some info here as well:

Answer 11

A class is a template for an object. It's the source code that tells the compiler what member variables and methods go into an object of that type of class.

An object and an instance are really the same. From the class template you can create many instances (or objects) of the class. Each one has all the members and methods defined in the class, in its own memory (although you can have shared members, and methods are almost always shared between instances).

Answer 12

By using an analogy for house blueprints.

The blueprint is a class. It specifies lots of details, but also leaves out a lot of properties, like the color of the house, the color and style of the front door, etc. You know, by checking the blueprint, where the door is going to be though, and that there is a door.

An object is the house you build from that blueprint. You can have many houses built from the same blueprint. They all have the same overall look and layout, but properties might vary, like the color of outside paint, the style of the front door, etc. The front door is in the same place on all the houses though.

You can call each of these houses instances of the house from the specific blueprint.

So, as @yx so eloquently said, an object is an instance of a class.