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 long as the object has only one purpose/responsibility is should not be divided anymore (unless it is too large which should not be the case).

Make objects as long as you can divide and conquer them after that. If you make to many small objects you will not be able to handle well all. On the other other side to few big objects cannot be reused easily.

My advice: practice! While practicing you will get a sense of what granularity you need - there is no general rule for this.

Answer 2

Another way to look at it is whether or not the doorknob is interchangeable. I would make the doorknob a separate object that is a property on the door. One question is whether or not you want to make the doorknob a private class if only the door can have that knob. I personally prefer not use a private class here, but is a legitimate possibility. By using a separate object as a property on the door, you can now move that instance of the knob from one door (instance) to another (like exchanging knobs from one door to another in your house).

Another interesting aspect of this is extending your hierarchy... You might have fancy knobs, lockable knobs, etc, which can all be implemented by extending your base door knob.

I hope that helped a little to clarify your confusion.

Answer 3

The textbook way of deciding on object granularity is to go by cohesion.

If most of the methods of your object operates on most of the object's fields, then the object is small enough (For a given value of "most").

An object is almost never too small.

Answer 4

The door knob would be a separate object in most cases, that can be assigned to a door-object.

An excessive use of objects would say:
There's an object for the lock, there is a color object for each color ("brownish" for the door, "silver" for lock and knob), and material objects ("wood" for the door and "steel" for knob and lock)
Here you can see the difference between a class and an object:

A class is an abstract (not in the sense of the programming language) form of something. You can refer something as a knob and everone knows what it is. You know that a knob has a color and a material.

If you buy a knob, you have a concrete knob-object in your hand, with a specific color and material. You can now change the color of you knob object, e.g. paint it black.

But there's a big diffenrence in programming objects and real-life objects. These basic examples only help to understand basic principles of OOP. You should let loose of this very soon!

(For those who are curious: Is a rectangle a square or a square a rectangle?)

Answer 5

As the old cliche says "objects should be nouns". Any time you find yourself thinking of a thing, it should probably be an object. Any time you find yourself thinking of an action, it should probably be a function or method.

Of course, there are exceptions to the above rules, and reality can be a bit more complex. However, this is probably the best starting place to start wrapping your head around the concept.

Answer 6

It is an object if you need to think about it as... an object.

That is, if you need an abstraction.

The "key hole" in your example can be described on different levels of abstraction and only the last one from the list you would probably call "an object":

1) Could be a boolean property, if you just need to know that your door has it:

---

class Door
{
    bool HasKeyHole;
}

---

2) Could be a pair of coordinates, if you just want to draw your door and put a circle in place of the key hole

---

 class Door
 {
    Point KeyHoleCoordinates;
 }

---

3) Could be a specially defined class KeyHole if you want to encapsulate logic and some properties of a key hole and work with them together, probably passing them around, or allowing interaction with a Key

---

class KeyHole
{
    Point Coordinates;
    bool OpensWithKey(Key key);
}

class Door
{
    KeyHole Hole;
}

---