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

I'd advise you to think about how you are going to use it. Think what operations you will have to do with your "thing" and then consider what would be the easiest way of doing it. Sometimes it will be easier to make it a property of another object, sometimes it will be easier to make it a new object of its own.

There is no universal recipe, there can be many factors that make one solution the better one. Just consider each case separately.

Added: To take your example about a door/doorknob/keyhole - what will you do with the keyhole? Here are some factors that would make it logical to make the keyhole as a separate object:

• You want store many properties of the keyhole like size, shape, direction, count of pins, whether the key can be turned once or twice, etc;
• There can be more than one keyhole on a doorknob;
• You want to give the keyhole some read-only properties (like whether it's locked or not) and then only allow modifying them through specific methods (like an "unlock" method which takes a "key" object as a parameters);
• Keyholes are stored in a separate DB table with one keyhole per DB row (then it might make sense to make the keyhole object mimic the DB structure);
• There are methods in your system that would be implemented in an elegant way if they could take a keyhole as a parameter;

The scenarios for making it a property are the opposite:

• Each doorknob can have only one keyhole and it has only one or very few properties;
• Keyholes are stored together with the doorknobs in the DB;
• You usually don't care about the keyhole alone, you just want it as a descriptive property of the doorknob (like whether or not there is one);

Answer 2

Everything is an object. From quarks over electrons, atoms to elements, dust, men, cars, the world and the universe.

Even thoughts, ideas or feelings are objects.

(So far for the obvious answer)

Coming to "deciding what deservers to be an object"; I alawys to it as simple as does it have to behave in any way and will it be used more than once.

As soon as you use anything more than once, it's worth being a function or even an object.

Furthermore; will it be reused by other things? (Objects, Projects, Programs, etc.) These are the thoughts I have when I decide what should and what sould not be an object.

But, as I said above, the question is trivial, as everything is an object by itself.

Answer 3

You should also think about how many of the sub-objects you need. A door has one handle not four or five and not a list of handles. Also do the sub-objects have properties of their own? Is the color or the material important? Then better keep the handle as a separate object.

Answer 4

Good old Plato already had an answer (kind of)...

But your question depends a lot on the language you're using, so there's no universal truth here. In some languages a thing should be a class, but it might be an object in others, or both (in those that have meta object protocols), or just a record of values and related functions.

Answer 5

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 6

Everything is an object. Sometimes you just use a primitive variable (int) to represent an object, and sometimes you create a data structure (struct/class). And naturally, some objects are parts of other objects.

So, yes, if you have to do in your code something with that part in the middle where you insert the key, it should also be an object in your code. It may be represented just by string Keyhole and may be represented by a class Keyhole, it may be an independent object and may be a part of the class DoorKnob - but anyway it will be an object.

In order to decide, whether an object should be independent, or should it be a part of a bigger object, you can just ask: Is it needed in the context outside the bigger object, or is it just a part of the bigger object's implementation.