OOP: When is it an object?

Question

I'm trying to understand object orientation. I understand it a little bit of course, but sometimes I'm not 100% clear. How do you decide what should be turned into an object (small object part of another big whole object) or what is not worth being an object, or maybe it should be just a property of that big whole object?

For a door, I guess the door knob should be an independent object, but should that part in the middle where you insert the key also be an independent object or what? This is a simple example so I can explain my confusion. You can use your example if it helps you make your point better.

I was thinking that if maybe I'm going to use it multiple times, I should make it an object. This I think is a practical way to resolve this problem, do you agree?

Thanks

Answer 1

As always, the answer is unfortunatly: it depends...

At the beginning, you have some sort of environment and you want to create a model for it. But you would not model every thing, you'll concentrate on the important things. That's why I started with: it depends. It depends on what details you need to accomplish the task.

Take the car and it's wheels - if you model a city and want some traffic, you may create a 'Car' class with the attribute 'numberOfWheels'. But if you design cars, then you most likely want to create a class 'Wheel' aswell and add four of those to the 'Car' class.

Rule of a thumb:

1. if that, what you're thinking about, has more then one attribute, define a class
2. if that, what you're thinking about, has some behavior, define a class
3. if that, what you're thinking about, may grow or be extended, define a class
4. if that, what you're thinking about, has to be sortable, comparable, define a class
5. if you're unsure, define a class ;)

Edit

Because you emphasized the 'multiple usage' aspect: I don't think that this is an aspect for a decision whether to use a class or not. Think of a simple counter, an integer value in a for loop. You'll use this concept hundreds of times but I bet you'll never think of wrapping this poor little int into a 'Counter' class - just because you use the 'concept of a counter' multiple times.

Answer 2

First: forget about physical objects. I know that all of the textbooks "learning examples" use them, but you're only going to confuse yourself when you try to model a real system. There is no direct relationship between physical objects and Objects.

An Object is a data structure combined with a set of methods that can operate on that data structure. The Properties of the Object hold the object state, and the methods operate on the state.

What is the system state you are trying to model? Does that reside in the door, the knob, or some combination of the two?

There are some methodologies that attempt to get the object model clearly specified before coding begins. Other methodologies (e.g, TDD) allow the object model to emerge through the coding process. In your case, I'd recommend coding some small-to-medium sized applications using TDD, so that you can see the advantages and disadvantages to various patterns. There's rarely one "right" way to model a given situation, but some models are much easier to use and understand than others; recognizing the patterns that apply to the situation in front of you comes with experience.

So, bottom line: make a lot of models. Think of application domains, model them, and code. In doing so, things will become much clearer. Make a sandbox, and jump in.