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 (

Answer 1

One way of finding out when you need to create an object and when not is to write down a short description of what you are trying to accomplish in plain language. If you are happy that you managed to express the problem in your description you can then pick the objects from that text as candidate classes. Then remove those that are obviously not needed.

Of course you will usually add many more classes to your SW and you will still remove some that you chose this way, but this is a starting point that I have used often. I usually end up drawing a crude ER diagram after this which further clarifies which classes I need. I also look at the candidate classes for similarities for inheritance purposes.

So if you feel the need to explain the keyhole in your short description then it's a good candidate for a class. If not, it might later still become apparent that you need a separate class for it but at that point you should already have a good idea of what you are doing in any case.

Answer 2

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 3

When deciding if something is an object or not, ask yourself if it has the following ...

State

Does the candidate have significant state? If it doesn't then all of the methods on it are likely to be only weakly related. In this case you've probably identified a library of module of reusable functions.

Behaviour

Does the object actually do something in the domain? For example is it just full of accessors which manipulate a struct or record.

Identity

Does the object really exist within the domain as an identifiable entity? Is there some innate aspect of the entity which distinguishes it from similar other entities? The door handle is an example - it doesn't really have identity since one door handle is likely to be the same as another.

If you answer no to some of these then you probably don't have an object - and that's fine a library or module can be a valuable reusable artifact

Above all, don't worry about it ...

I also wouldn't worry too much about the reuse aspect of this. Designing class hierarchies is like designing scalable software - it's too easy to optimise early. Sketch out a design on a piece of paper and if you can, validate the design with a few hand-drawn interaction diagrams. You'll find that over time you'll develop a real insight into what's really valuable and reusable.

Answer 4

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 5

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 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;
}

---