Editing Mutator method (section)

==Implications==
The alternative to defining mutator and accessor methods, or [[Property (programming)|property]] blocks, is to give the [[instance variable]] some [[Information hiding|visibility]] other than private and access it directly from outside the objects. Much finer control of access rights can be defined using mutators and accessors. For example, a parameter may be made read-only simply by defining an accessor but not a mutator. The visibility of the two methods may be different; it is often useful for the accessor to be public while the mutator remains protected, package-private or internal.

The [[block (programming)|block]] where the mutator is defined provides an opportunity for [[Data validation|validation]] or preprocessing of incoming data. If all external access is guaranteed to come through the mutator, then these steps cannot be bypassed. For example, if a date is represented by separate private <code>year</code>, <code>month</code> and <code>day</code> variables, then incoming dates can be split by the <code>setDate</code> mutator while for consistency the same private instance variables are accessed by <code>setYear</code> and <code>setMonth</code>. In all cases month values outside of 1 - 12 can be rejected by the same code.

Accessors conversely allow for synthesis of useful data representations from internal variables while keeping their structure encapsulated and hidden from outside modules. A monetary <code>getAmount</code> accessor may build a string from a numeric variable with the number of decimal places defined by a hidden <code>currency</code> parameter.

Modern programming languages often offer the ability to generate the [[Boilerplate code|boilerplate]] for mutators and accessors in a single line&mdash;as for example C#'s <code>public string Name { get; set; }</code> and Ruby's <code>attr_accessor :name</code>. In these cases, no code blocks are created for validation, preprocessing or synthesis. These simplified accessors still retain the advantage of encapsulation over simple public instance variables, but it is common that, as [[Agile software development|system designs progress]], the software is [[Software maintenance|maintained]] and requirements change, the [[Data integrity|demands on the data]] become more sophisticated. Many automatic mutators and accessors eventually get replaced by separate blocks of code. The benefit of automatically creating them in the early days of the implementation is that the public interface of the class remains identical whether or not greater sophistication is added, requiring no extensive refactoring if it is.<ref>{{cite web
|url=http://www.safnet.com/writing/tech/archives/2009/04/automatic_prope.html
|title=Automatic Properties in C# 3.0
|author=Stephen Fuqua
|year=2009
|accessdate=2009-10-19
|archive-url=https://archive.today/20110513104930/http://www.safnet.com/writing/tech/archives/2009/04/automatic_prope.html
|archive-date=2011-05-13
|url-status=dead
}}</ref> 

Manipulation of parameters that have mutators and accessors from ''inside'' the class where they are defined often requires some additional thought. In the early days of an implementation, when there is little or no additional code in these blocks, it makes no difference if the private instance variable is accessed directly or not. As validation, [[cross-validation (statistics)|cross-validation]], [[data integrity]] checks, preprocessing or other sophistication is added, subtle [[Software bug|bugs]] may appear where some internal access makes use of the newer code while in other places it is bypassed.

Accessor functions can be less efficient than directly fetching or storing data fields due to the extra steps involved,<ref>{{cite web
|url=https://www.scribd.com/doc/53104779/Run-Time-Efficiency-of-Accessor-Functions
|title=Run Time Efficiency of Accessor Functions 
|author=Tim Lee
|date=1998-07-13
}}</ref> however such functions are often [[Inline function|inlined]] which eliminates the overhead of a function call.