Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Компьютерлік ғылымда мутатор әдісі – айнымалының өзгерістерін басқару үшін қолданылатын әдіс. Олар сондай-ақ сеттер әдістері деп кеңінен танымал. Көбінесе сеттер жеке мүше айнымалысының мәнін қайтаратын геттермен бірге қолданылады. Бұлар жиынтығында аксессуарлар деп те аталады. Мутатор әдісі көбінесе объектіге бағытталған бағдарламалауда инкапсуляция принципіне сәйкес қолданылады. Осы принципке сәйкес, кластың мүше айнымалылары оларды жасыру және басқа кодтан қорғау үшін жеке болып жасырылады, оларды тек қалаған жаңа мәнді параметр ретінде қабылдайтын, қажет болса тексеріп, жеке мүше айнымалысын өзгертетін ашық мүше функциясы (мутатор әдісі) арқылы ғана өзгертуге болады. Мутатор әдістерін тағайындау операторын жүктеумен салыстыруға болады, бірақ олар әдетте объектілік иерархияның әртүрлі деңгейлерінде кездеседі. Мутатор әдістерін объектіге бағытталмаған ортада да қолдануға болады. Бұл жағдайда, өзгертілмекші айнымалыға сілтеме және жаңа мән мутаторға беріледі. Мұндай жағдайда компилятор кодты мутатор әдісін айналып өтіп, айнымалыны тікелей өзгертуден шектей алмайды. Дамытушылар айнымалы тек мутатор әдісі арқылы ғана өзгертілетініне және тікелей өзгертілмейтініне көз жеткізуге жауапты. Оларды қолдайтын бағдарламалау тілдерінде қасиеттер инкапсуляцияның тиімділігінен айырылмастан, ыңғайлы балама ұсынады. Төмендегі мысалдарда толыққанды іске асырылған мутатор әдісі кіріс деректерін тексеруге немесе оқиғаны іске қосу сияқты қосымша әрекеттерді орындауға қабілетті.
In computer science, a mutator method is a method used to control changes to a variable. They are also widely known as setter methods. Often a setter is accompanied by a getter, which returns the value of the private member variable. They are also known collectively as accessors. The mutator method is most often used in object oriented programming, in keeping with the principle of encapsulation. According to this principle, member variables of a class are made private to hide and protect them from other code, and can only be modified by a public member function (the mutator method), which takes the desired new value as a parameter, optionally validates it, and modifies the private member variable. Mutator methods can be compared to assignment operator overloading but they typically appear at different levels of the object hierarchy. Mutator methods may also be used in non object oriented environments. In this case, a reference to the variable to be modified is passed to the mutator, along with the new value. In this scenario, the compiler cannot restrict code from bypassing the mutator method and changing the variable directly. The responsibility falls to the developers to ensure the variable is only modified through the mutator method and not modified directly. In programming languages that support them, properties offer a convenient alternative without giving up the utility of encapsulation. In the examples below, a fully implemented mutator method can also validate the input data or take further action such as triggering an event.
Салдары
Мутаторлар мен аксессор әдістерін немесе қасиеттер блоктарын анықтаудың орнына, инстанция айнымалысына жеке емес көрінетіндік беріп, объектілерден тысқары тікелей қол жеткізуге болады. Мутаторлар мен аксессорларды қолдану арқылы кіру құқықтарын әлдеқайда жақсы бақылауға болады. Мысалы, параметрді тек аксессор арқылы оқуға болады, мутаторды анықтамай. Екі әдістің көріну деңгейі әртүрлі болуы мүмкін; көбінесе аксессордың ашық болуы тиімді, ал мутатор қорғалған, пакеттік жеке немесе ішкі болуы мүмкін. Мутатор анықталған блок кіріс деректерін тексеруге немесе алдын ала өңдеуге мүмкіндік береді. Егер барлық сыртқы қолжетімділік мутатор арқылы жүзеге асырылса, онда осы қадамдарды айналып өту мүмкін емес. Мысалы, егер күнді жеке жыл, ай және күн айнымалыларымен көрсетілсе, кіріс күндері setDate мутаторымен бөлінеді, ал сәйкестік үшін сол жеке инстанция айнымалыларына setYear және setMonth арқылы қол жеткізіледі. Барлық жағдайларда 1 мен 12-ден тыс ай мәндері бірдей кодпен қабылдамауға болады. Аксессорлар керісінше, ішкі айнымалылардан пайдалы деректерді құруға мүмкіндік береді, сонымен бірге олардың құрылымын сыртқы модульдерден жасырып, капсулациялайды. Ақша сомасын алуға арналған аксессор (getAmount) жасырын валюта параметрімен анықталған ондық таңбалар саны бар сандық айнымалыдан жол құрауы мүмкін. Қазіргі заманғы бағдарламалау тілдері көбінесе мутаторлар мен аксессорлардың қалыпты үлгісін бір жолда жасауға мүмкіндік береді, мысалы, C#-тағы public string Name { get; set; } және Ruby-тегі attr_accessor :name. Бұл жағдайларда тексеру, алдын ала өңдеу немесе құрастыру үшін код блоктары жасалмайды. Бұл жеңілдетілген аксессорлар әлі де қарапайым ашық инстанция айнымалыларына қарағанда капсулацияның артықшылығын сақтайды, бірақ жүйелік жобалау дамыған сайын, бағдарламалық құралдарды күтіп ұстау және талаптар өзгергенде деректерге қойылатын талаптар күрделене түседі. Көптеген автоматты мутаторлар мен аксессорлар ақырында жеке код блоктарымен ауыстырылады. Оларды іске асырудың алғашқы кезеңдерінде автоматты түрде жасаудың пайдасы – сыныптың ашық интерфейсі күрделілік қосылған жағдайда да өзгермейді, бұл кең ауқымды қайта құруды қажет етпейді. Мутаторлары мен аксессорлары бар параметрлерді олар анықталған сыныптың ішінде манипуляциялау көбінесе қосымша ойлауды қажет етеді. Егер осы блоктарда қосымша код болмаса немесе одан да аз болса, іске асырудың алғашқы кезеңдерінде жеке инстанция айнымалысына тікелей қол жеткізу маңызды емес. Тексеру, өзара тексеру, деректердің тұтастығын тексеру, алдын ала өңдеу немесе басқа күрделіліктер қосылғанда, кейбір ішкі қолжетімділіктер жаңа кодты пайдаланса, ал басқа жерлерде оны айналып өтуге болады. Аксессор функциялары қосымша қадамдардың болуына байланысты деректерді тікелей алу немесе сақтаудан тиімсіз болуы мүмкін, бірақ мұндай функциялар көбінесе функция шақыруының қосымша шығындарын жоятын желіде орналастырылады.
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.