CODEWITHSUNDEEP
c#oop
tmakino
tmakino

Reputation: 648

When to check the state of an object, general OOP, example in C#

I'm not quite sure how to word this question in a sentence so I had difficulty searching previous posts. This comes up frequently for me and I'd like to get consensus on how to approach it.

Say you have two classes, ExampleClass and ExampleClassManager. ExampleClass has an Update(Data data) method which is called from ExampleClassManager. However, ExampleClass can be in one of two states, and in the Enabled state it wants to process the data passed to it in Update, and in the disabled state it doesn't do anything with the data at all.

Should I be checking for the state in the ExampleClassManager and not passing the data at all if it is disabled, or should I pass the data regardless and ignore it within ExampleClass?

Here's a code example in case I didn't articulate it clearly. 

public class ExampleClass {
    public bool Enabled {
        get;
        set;
    }

    public void Update(Data data) {
        if(Enabled) {
            //do stuff with data
        }
    }
}

public class ExampleClassManager {
    private List<ExampleClass> exampleClassList=new List<ExampleClass>();

    public void UpdateList() {
        foreach(ExampleClass exampleClass in exampleClassList) {
            exampleClass.Update(data);
        }
    }
}

or

public class ExampleClass {
    public bool Enabled {
        get;
        set;
    }

    public void Update(Data data) {
        //do stuff with data
    }
}

public class ExampleClassManager {
    private List<ExampleClass> exampleClassList=new List<ExampleClass>();

    public void UpdateList() {
        foreach(ExampleClass exampleClass in exampleClassList) {
            if(exampleClass.Enabled) {
                exampleClass.Update(data);
            }
        }
    }
}

Upvotes: 5

Views: 1993

Answers (4)

Willem Toerien
Willem Toerien

Reputation: 260

Let's say you have two objects, Company and Employee. Do you have the company check when the employee is hungry, or do you have the employee check if he is hungry? Sounds like you want the employee to check if he is hungry, right? But what if the company wants to order food for all the employees, then the company needs to check if the employee is hungry.

So my point is, it depends on the design and the context of when to check and who is checking and why. In your example, I would say it doesn't matter because the context isn't set.

Upvotes: 0

Fabio Marcolini
Fabio Marcolini

Reputation: 2385

I'd choose option 2, classManager should manage the objects, he should know whether fire the update or not. The update method of the single object should do what it says (update the object and not doing nothing).

@caerolus: I can't comment yet... anyway neither of the example given broke the law of demeter

Anyway I think this is a somewhat personal choice question, maybe it's more suitable for stack exchange?

Upvotes: 0

Juli&#225;n Urbano
Juli&#225;n Urbano

Reputation: 8488

Given that it depends on a property of ExampleClass, I'd choose option 1 and check within ExampleClass.Update. Otherwise, any object with access to an ExampleClass object could call Update regardless of the state. By checking within the Update method, you make sure it will only proceed if the object is enabled. The question here is who can change the object's status?

See the Law of Demeter:

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

Upvotes: 3

Scott Mermelstein
Scott Mermelstein

Reputation: 15397

"How much management should my manager class do?" Your option 2 is the "micromanagement" approach - that the Manager should dictate every little detail to the ExampleClass about what it should do and how.

Typically, that's more structure-based programming than object oriented programming. I would expect your manager to tell your object "go do this", and not worry about the details. The ExampleClass should encapsulate all of its behavior internally, and not force the manager to worry about it.

My vote is for option 1, with the caveat that these are general principles, and you'll always be able to find some case where you want option 2.

One question to ask - is there a reason that ExampleClass.Enabled.get is public, aside from letting the manager check? If that's the only reason it's public, then it's internal implementation, and the gettor should be private. If you have a lot of things looking at this field, that could imply your option 2 workflow is more natural for this class.

Upvotes: 0

Related Questions