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.

Solution 1

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 well.

• 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(), Brake(), 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 chassis, 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 want 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 their Vehicle class and then calling 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.

Solution 2

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.

Solution 3

in one sentence:

an Object is an Instance of a Class

Solution 4

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.

Solution 5

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.

View more solutions