How to design objects?

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.

Answer 2

Don't start out by classifying things - seems like people are too eager to start building inheritance hierarchies.

write down a list of specific, concrete scenarios - what your app will do, step by step. An object model is only useful if it does what you need it to do - so start working back from the scenarios to see what common objects and behaviours you can shake out of each one.

identify the "roles" in your scenarios - not necessarily actual class names - just vague "roles" that turn up when you think through concrete scenarios for how your software will work. These roles might later become classes, interfaces, abstract classes - whatever you need - at the start they're just placeholders for doing a type of work.

Work out what each role "does". The key is having a bunch of named roles - that identify things that the objects will do. Thins is about distilling out a set of things each role can do - they might do the whole thing, or put together a bunch of other objects to do the work, or they might co-ordinate the work... it depends on your scenarios.

The most important thing in OOD/OOP - is OBJECTS DO THINGS - not what's inside them - what they do.

Don't think about inheritance early on - because it will tie you up in overcomplicated hierarchies and make you think in terms of SQL-oriented programming rather than object-oriented programming. Inheritance is just one way of sharing common code. There are lots of other ways - delegation, mixins, prototype-based programming...

Here are some guidelines I came up with to help with this:

What should be on a checklist that would help someone develop good OO software?