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

This depends a bit on the usage. To go with your example, if the doorknob is an important part and could (potentially) be used on another door (or a different knob be used for 'this' one) then it should probably be an object.

If on the other hand it is only there to allow you to open and close the door, it should simply be a part of the door object.

Answer 2

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 3

I answered this already in another question

Code objects are not related to tangible real-life objects; they are just constructs that hold related information together.

Don't believe what the Java books/schools teach about objects; they're lying.

Just write something that gets the job done, even if it's ugly, then refactor continuously:

• eliminate duplicate code (don't repeat yourself)
• increase cohesion
• reduce coupling

But:

• don't over-engineer; keep it simple
• don't write stuff you ain't gonna need

If you don't end up with massive (and useless) class hierarchy, then you have done a good job, producing elegant and clean code.

Remember: OOP is a means, not an end.

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

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 6

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.