Question

I've been having an argument about the usage of the word "accessor" (the context is Java programming). I tend to think of accessors as implicitly being "property accessors" -- that is, the term implies that it's more or less there to provide direct access to the object's internal state. The other party insists that any method that touches the object's state in any way is an accessor.

I know you guys can't win the argument for me, but I'm curious to know how you would define the term. :)

Was it helpful?

Solution

By accessors, I tend to think of getters and setters.

By insisting that all methods that touch the object's internal state are accessors, it seems that any instance method that actually uses the state of the object would be an accessor, and that just doesn't seem right. What kind of instance method won't use the state of the object? In other words, an instance method that doesn't use the object's state in some way shouldn't be an instance method to begin with -- it should be a class method.

For example, should the BigDecimal.add method be considered an accessor? It is a method that will read the value of the instance that the add method was called on, then return the result after adding the value of another BigInteger. It seems fairly straight forward that the add instance method is not a getter nor a setter.

OTHER TIPS

An accessor method does exactly what it says on the tin: accesses some state from the type without side effects (apart from lazy instantiation, perhaps, which is not something that the caller would normally know about).

private int _age;

public int getAge()
{
    return _age;
}

Methods that modify state are more usefully considered (in my opinion) as mutators.

Besides googling and wikipedia, the Java Language Specification shows this as an example of an accessor method:

private static int N;
public static int getN() { return N; }

So, yes, I'd say it just gets the value of a field. The compiler may inline this, converting it to a simple read, so anything more than that probably isn't an accessor.

Accessor methods : getRed, getGreen, and getBlue

These methods usually access a value.

Mutator methods : setRed, setGreen, setBlue

A mutator will mutate a value

I've always gone by the first definition. So, generally that applies just to getters and setters. If we go by the second method, then it's a far less useful distinction, since that covers almost all methods.

Accessor methods are used to access fields of an object. So getters and setters are both accessor methods. Observer method is the right term for a method that makes a more general observation about an object, without causing externally observable side effects. A method whose primary purpose is to cause side effects is a mutator method. Therefore, setters are an example of a mutator method. For good engineering practice, public setters should be avoided because they make it impossible for a class to enforce invariants on its data: they violate the abstraction barrier that a class should ordinarily enforce.

It is good to be able to differentiate getters and setters in technical conversation. Accessor methods are partners to modifier methods. Accessors read the state of an object (getA()), while modifiers write the state (setA(Object)).

A method that provides access (can be 'read access' or 'write access') to the internals of an object is an 'accessor method'.

The authors here certainly uses it in this manner:

  1. http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html

  2. http://c2.com/cgi/wiki?AccessorsAreEvil

I think the term may originate from Common Lisp (doesn't everything?) -- with setf used to modify the value of accessor slots.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top