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

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.

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