117 |
С т р а н и ц а
Метод мутатора предполагает предотвращение принятия отрицательного
значения внутренним элементом данных hp. Вы можете рассматривать метод
мутатора отчасти имеющим обратную силу. Должна ли ответственность лежать на
вызывающем коде, в проверке значения, которое он установил до вызова setHp(-
2), и не допускать этого, как только оно попадается в
методе мутатора? Можете ли
вы использовать публичную переменную-член и возложить ответственность в
проверке того, что переменная не принимает недействительных значений в
вызове кода, а не в сеттере? Да, вы можете.
Тем не менее, это суть применения метода мутатора. Идея
метода мутатора в том,
что вызывающий код может передавать любое значение которое он хочет для
функции setHp (например, setHp(-2)), без необходимости беспокоиться о том,
будет ли значение, передаваемое функции, пригодным или нет. Затем функция
setHp принимает ответственность, в том, чтобы убедиться, является ли значение
для переменной hp пригодным.
Некоторые программисты считают прямые
функции мутатор, такие как
getHp()/setHp() дурно пахнущим кодом. Дурно пахнущий код – это в целом плохая
практика программирования, которую откровенно не замечают, за исключением
лёгкого чувства, что, что-то было сделано не оптимально. Они спорят о том, что
вместо мутаторов могут быть написаны функции-члены более высокого уровня.
Например, вместо
функции-члена setHp() у нас должны быть публичные функции-
члены, такие как
восстанавливать()
и
наноситьУрон()
. Статья по этой теме доступна на
http://c2.com/cgi/wiki?AccessorsAreEvil
.
Достарыңызбен бөлісу: