Question

So there are many ways of structuring objects (I’m talking of OOP here). For the question, I will use the classic “Car” example of OOP. Basically, How do I know when to make the car an object, or the wheel of a car an object, when both program structures would accomplish the goal?

How do I classify and categorize the parts of an object to determine whether or not they are better suited as simple attributes or variables of an object, or if they really need to be an object themselves?

Answer 1

Well the first thing you have to realize is the OOAD (“Object-oriented analysis and design”) is a tool and not a means to an end. What you get out of that process is a model, not a true representation of what you’re modelling. That model makes certain assumptions. The purpose of that model is to solve a problem you have.

So how do you know how to design objects? How do you know if you’ve done it right? By the end result: has it solved your problem?

So, for the Car example, in some models a car count could simply be an integer count, for example the car traffic through an intersection in a traffic model. In such a model rarely do you care about the make, model or construction of cars, just the number. You might care about the type of vehicle to the point of is it a truck or car (for example). Do you model that as a Vehicle object with a type of Car or Truck? Or just separate carCount and truckCount tallies?

The short answer is: whichever works best.

The normal test for something being an object or not is does it have behaviour? Remember that ultimately objects = data + behaviour.

So you might say that cars have the following state:

• of wheels;

• Height of suspension;
• Left or right drive;
• Colour;
• Width;
• Weight;
• Length;
• Height;

• of doors;

• Whether it has a sunroof;
• Whether it has a stereo, CD player, MP3 player and/or satnav;
• Size of the petrol tank;
• Number of cylinders;

• of turbo charges and/or fuel injection;

• Maximum torque;
• Maximum brake-horsepower;
• and so on.

Chances are you’ll only care about a small subset of that: pick whatever is relevant. A racing game might go into more detail about the wheels, such as how hot they are, how worn, the width and tread type and so on. In such a case, a Wheel object could be said to be a collection of all that state (but little behaviour) because a Car has a number of Wheels and the Wheels are interchangeable.

So that brings up the second point about objects: an object can exist because of a relationship such that the object represents a complete set of data. So a Wheel could have tread, width, temperature and so on. You can’t divide that up and say a Car has tread but no wheel width so it makes sense for Wheel to be an object since a Wheel in it’s entirety is interchangeable.

But again, does that make sense for what’re doing? That’s the key question.