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

In general, if you need more information from it than just only one thing (not only the knob's state, but also its color, its exact location, whether it has a key groove, the ability to change its state/behaviour, etc), then make it object. Thus, when you can't store all the information the door needs to know about the knob in a simple String, Number or Boolean, then make it an fullworthy Knob.

As everywhere you also have "corner cases". I see this often with pairs. Two propeties which are related to each other, but usually to nothing else. They aren't always grouped in a separate real world object. For example sortDirection and sortField. Whether they belongs in their own object depends on what the parent object represents. Is it a sortable implementation of List? Okay, keep it there. Is it a Door? Well, I would maybe externalize it.

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.