Методы-мутаторы: управление изменениями переменных в программировании

Введение

В информатике метод-мутатор — это метод, используемый для управления изменениями переменной. Они также широко известны как методы-сеттеры. Часто сеттер сопровождается геттером, который возвращает значение приватной переменной-члена. Все вместе они также известны как методы доступа. Метод-мутатор наиболее часто используется в объектно-ориентированном программировании, в соответствии с принципом инкапсуляции. Согласно этому принципу, переменные-члены класса делаются приватными, чтобы скрыть и защитить их от другого кода, и могут быть изменены только через публичный метод-член (метод-мутатор), который принимает желаемое новое значение в качестве параметра, опционально выполняет его проверку и изменяет приватную переменную-член. Методы-мутаторы можно сравнить с перегрузкой оператора присваивания, но они обычно встречаются на разных уровнях объектной иерархии. Методы-мутаторы также могут использоваться и в не объектно-ориентированных средах. В этом случае мутатору передается ссылка на переменную, которую необходимо изменить, вместе с новым значением. В этом сценарии компилятор не может предотвратить обход метода-мутатора и прямое изменение переменной. Ответственность за то, чтобы переменная изменялась только через метод-мутатор, а не напрямую, ложится на разработчиков. В языках программирования, которые их поддерживают, свойства предлагают удобную альтернативу, не отказываясь от преимуществ инкапсуляции. В приведенных ниже примерах полностью реализованный метод-мутатор также может проверять входные данные или выполнять другие действия, например, вызывать событие.

Последствия

Альтернатива определению методов мутатора и аксессора, или блоков свойств, заключается в предоставлении переменной экземпляра видимости, отличной от приватной, и доступе к ней напрямую извне объектов. Мутаторы и аксессоры позволяют реализовать гораздо более тонкий контроль над правами доступа. Например, параметр можно сделать доступным только для чтения, определив только аксессор, но не мутатор. Видимость этих двух методов может различаться: часто бывает полезно, чтобы аксессор был публичным, а мутатор оставался защищенным, доступным только в пределах пакета или внутренним. Блок, в котором определяется мутатор, предоставляет возможность для проверки или предварительной обработки входящих данных. Если весь внешний доступ гарантированно осуществляется через мутатор, то эти шаги нельзя будет пропустить. Например, если дата представлена отдельными приватными переменными год, месяц и день, то входящие даты могут быть разделены мутатором `setDate`, а для обеспечения согласованности к тем же приватным переменным экземпляра обращаются методы `setYear` и `setMonth`. Во всех случаях значения месяца, выходящие за пределы 1–12, могут быть отклонены одним и тем же кодом. Аксессоры, напротив, позволяют синтезировать полезные представления данных из внутренних переменных, сохраняя при этом их структуру инкапсулированной и скрытой от внешних модулей. Аксессор `getAmount` для денежных значений может создавать строку из числовой переменной, при этом количество десятичных знаков определяется скрытым параметром валюты. Современные языки программирования часто предлагают возможность генерировать шаблонный код для мутаторов и аксессоров в одну строку, например, `public string Name { get; set; }` в C# и `attr_accessor :name` в Ruby. В этих случаях блоки кода для валидации, предварительной обработки или синтеза не создаются. Эти упрощенные аксессоры по-прежнему сохраняют преимущество инкапсуляции по сравнению с простыми публичными переменными экземпляра, но часто, по мере развития архитектуры системы, когда программное обеспечение поддерживается и требования меняются, требования к данным становятся более сложными. Многие автоматически созданные мутаторы и аксессоры в конечном итоге заменяются отдельными блоками кода. Преимущество автоматического создания их на ранних этапах реализации заключается в том, что публичный интерфейс класса остается неизменным, независимо от того, добавляется ли более сложная логика, что избавляет от необходимости масштабного рефакторинга. Работа с параметрами, имеющими мутаторы и аксессоры, внутри класса, где они определены, часто требует дополнительного внимания. На ранних этапах реализации, когда в этих блоках содержится мало или совсем нет дополнительного кода, не имеет значения, осуществляется ли прямой доступ к приватной переменной экземпляра или нет. Однако по мере добавления валидации, перекрестной валидации, проверок целостности данных, предварительной обработки или других усложнений могут возникать скрытые ошибки, когда некоторый внутренний доступ использует новый код, а в других местах он обходит его. Функции-аксессоры могут быть менее эффективными, чем прямое получение или сохранение полей данных из-за дополнительных шагов, но такие функции часто оптимизируются путем встраивания, что устраняет накладные расходы на вызов функции.

The alternative to defining mutator and accessor methods, or property blocks, is to give the instance variable some 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 where the mutator is defined provides an opportunity for 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 year, month and day variables, then incoming dates can be split by the setDate mutator while for consistency the same private instance variables are accessed by setYear and setMonth. 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 getAmount accessor may build a string from a numeric variable with the number of decimal places defined by a hidden currency parameter. Modern programming languages often offer the ability to generate the boilerplate for mutators and accessors in a single line—as for example C#'s public string Name { get; set; } and Ruby's attr accessor :name. 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 system designs progress, the software is maintained and requirements change, the 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. 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, data integrity checks, preprocessing or other sophistication is added, subtle 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, however such functions are often inlined which eliminates the overhead of a function call.