Naming convention for a method that both sets and gets

Question

Let's say we have a method setFoo that sets a flag in a Bar object e.g.

class Baz { 
    public void setFoo(String foo)(
       ...
    }
}

inside setFoo, the method is doing some expensive load of the Bar object from the database.

class Baz { 
    public void setFoo(String foo)(
       Bar bar = expensiveGetBar();
       ...
    }
}

To avoid the need to get the Bar object again, the developer changes the method to return it.

class Baz { 
    public Bar setFoo(String foo)(
       Bar bar = expensiveGetBar();
       ...
       return bar;
    }
}

Questions are:

1. Is this discouraged?
2. If yes, why and what is the alternative
3. Should the solution be adding some sort of cache instead?
4. How would you prefix the method? set? get? seget? geset?

Answer 1

A function should serve one purpose. That’s part of the reason it’s called a function. If you find a method hard to name because it’s doing more than one thing, then split it into more than one method. Readable method names can often be made from just one verb and one noun.

In your example, you could change setFoo() to take a Bar explicitly. As a setter, it shouldn’t really need to return anything. Then either expose expensiveGetBar(), or expose getBar() and have it cache the result of expensiveGetBar().

Answer 2

Here is my favorite solution for that problem:

class Baz { 
    Bar _bar;

    /* make this public if you like */ 
    Bar getBar()
    {
       if(_bar==null)
           _bar = expensiveGetBar();
       return _bar;
    }

    public void setFoo(String foo)
    {
       Bar bar = getBar();
       ...
    }
}

You may have to add a method to clear or update _bar, but that depends on your actual case.

Answer 3

Getters and Setters are a means to expose properties of classes. They are one-way functions. They either get (return a value) or they set (accept a value), but they don't do both in the same function. Even C# properties which do away the extra get and set functions maintains the one-way operation.

So if I have

• GetFoo()
• SetFoo()

Then there is an implied operation upon a property called Foo. Due to the magic of encapsulation, I don't really care if the internal object is called Foo. I just know that if I SetFoo() and then GetFoo() then there should be some degree of logical linkage between my operations.

So you don't have getters | setters in your example. Yes, I know they are named that way, but that's not what they're doing. The third snippet really shows the deviation from the concept of properties. public Bar setFoo(String foo) means I set a Foo but I get a Bar back? What?!

You need to pick a different verb than 'Set' to use in this case, because the function is not performing a set operation. Something like public Bar AnalyzeFoo(String foo) may be a more appropriate description of what the function is doing and still hides the fact that there is a really expensive operation on Bar as part of the function.

A more concrete example may help.

This next example is bad, for the reasons explained above:
public ProfitMargin SetInvoice(Invoice inv)

But this example makes more sense:
public ProfitMargin AnalyzeInvoice(Invoice inv)

I don't know or need to know how expensive of an operation it is to break apart the Invoice and identify the profit margin; the AnalyzeInvoice() function takes care of that for me.

---

A quick note on what I meant with C# properties...

Yes, I still have to define the get & set routines but they are expressed as part of the Property and don't require additional functions like Java used to require.

So in C#, I have:

private ____ xyz
public ____ MyProp {
   get { .... return xyz; }
   set { .... xyz = value; }
}

Whereas old-school Java required explicit functions:

private ____ xyz;
public ____ GetMyPrep() { ... return xyz; }
public void SetMyPrep(____ value) { ... xyz = value; }

Both work well, and modern IDEs simplify the getter | setter creation. The point is that both approaches are still one-way operations.

Answer 4

I would think you might do the following:

    bar = getExpensiveBar();
    setBarState(bar);

    setBarState( Bar myBar)
    {
       myBar.setFlag(true);
       myBar.setOtherFlag(false);
    }

But If the Bar object just has a flag then wouldn't you just do the following:

    bar = getExpensiveBar();
    bar.setFlag(true);