Clever Geek Handbook

Is it good practice to define a getter that doesn't return a specific field?

kind of a simple question. Are there methods like this good practice?

private NavigableMap<Double, Site> m_sites;

private Site getRandomSite()
{
    return m_sites.ceilingEntry(Math.random()).getValue();
}

Or is it bad because it is a getter and you can expect it to return a "randomSite" field?

+3


source to share


6 answers


The method is nice, although I understand that you don't want to call it getRandomSite()

because it is similar to a getter method. Based on Gio's answer, I suggest you call the method fetchRandomSite()

because, as you said, this method does not generate a random site, it just fetches (or fetches) it from the NavigableMap.



+3


source


If you, the author of the code, think this is confusing / bad in relation to the rest of your codebase, than change the name to eg generateRandomNumber()

. However, there is no convention that a "getter" should always return a field.



+3


source


Getter can get something back (get something back) Doesn't mean that it only returns some field value. No problem with your current method.

+2


source


No, this is bad practice. Methods like this should be static and encapsulated in utility classes, since they have nothing to assume that they are associated with the surrounding class. In addition, the utility class must have a private constructor, so it cannot be accidentally created.

A situation where it might be useful is MyClass.allocateNextUniqueKey (). But in this case, the method should not allocate a key that has already been used, so it definitely has a relationship with MyClass.

+1


source


If your method calculates something, perhaps the method name that explains this behavior is better:

private NavigableMap<Double, Site> m_sites;

private Site pickRandomSite()
{
    return m_sites.ceilingEntry(Math.random()).getValue();
}

In any case, whether it's a real getter (it's a bogus method for flaws in properties like C # or fear of public fields for an equivalent struct

) or not, the only thing that matters is that the method name reflects its purpose.

Example: Don't call a getSite()

method that returns a random node.

On the side of the note, what worries me is more than usage getRandomSite

- it is m_sites

. I know by asking that this is a company convention, but it seems like obfuscation to me (I hate member / method prefix on the scope naming convention).

0


source


There are several conventions regarding getters. If there is a getter, there can be a matching setter. This installer must take one parameter of the same type as the receiver. Some frames, for example. Spring can provide this.

Going back to your question, getters are expected to finally return a field. This does not mean that the field should be returned directly. It could be, for example, lazy-load or conversion (getDurationInMillis, getDurationInSeconds, ...), but is get-Methods really expected to return the same value if no changes are made. Math.random () seems to be a prime example for this. It's called random () instead of getRandom () because the values ​​change.

In conclusion, if a method does not fulfill all the expectations of a getter, it is probably better to name it differently. selection, search, ...

0


source






More articles: