3

I've been working with OOP for a while now, but in each large project that I find myself starting, I seem to run into the same problem; where does the responsibility reside.

Like many who use OOP on a regular basis, it becomes natural to start breaking things into nouns, verbs, adjectives, etc. Recently I read a post about whether or not an object can, or should, contain any state information, or if it should be only state information. During this post, I saw a response that mentioned Martin Fowler's Mark IV Coffee Maker. Everybody seemed to agree that breaking things out in that way was indicative of a good design. The problem I have is that I don't see it that way. To me, it seems backwards in some parts. I haven't been doing this for nearly as long as some of you have, so I'd like to ask if there's any what I can break this habit, or what I can do to change it.

One example we can consider is a light bulb. Let's say there are two use-cases, where a Person wants to turn on the light, and where a Person wants to turn off the light. This could be reduced to one use-case, where they want to toggle the light, potentially.

If I understand that example, the responsibility of Light turning on or off should be the responsibility of the Light object, with something like

public interface Light {
    void turnOn();
    void turnOff();
    void toggle();
}

However, when I think about this situation, a Light cannot turn itself off, or turn itself on. This happens in response to some sort of event, or action. My kitchen light usually doesn't turn on or off by itself. It's not intelligent. A Person or Switch can turn a light on or off; but a Light cannot. Its state is entirely determined by something else. So where should the responsibility reside? All of the projects I have been a part of, that I have ended up quitting, have boiled down to this question. What sort of tools, mental or physical, can I use to write more OO code?

Note: Most of the project I have worked on have been in Java; it is my most comfortable language. This question is more language-agnostic though.

  • 2
    That is why it is called "object" - an object that can be manipulated. Otherwise it would have been called "subject" or "freewill", I guess. (Sorry, I'm just joking. Don't take my comment seriously.) – rwong Jul 11 '15 at 7:29
7

The responsibility for getting something done should reside with the object that models the state that changes when you do it.

You're right that a lightbulb doesn't turn itself off. However, that's not what calling an object method means. The accepted mental model is sending a message to an object. In the real world you do this by flipping its associated switch. In the programming world, the caller invokes an object method with parameters. In both scenarios the bulb is passive and others act on it.

Therefore, bulb.toggle() is the preferred way of notating this action. Neither the person pressing the switch nor the switch itself are mentioned because what you care about is the state of the bulb (the room gets dark), not the state of the switch (the contact is without current) or the state of the person (slightly more tired from the effort?). The state of the person would only be relevant if you wrote a fitness app tracking the energy expended by the user. The state of the switch... actually, I can't think of a plausible scenario where you would want to model that.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.