Мы снова и снова слышали от ниндзя программирования, что методы получения и установки являются злом. На вопрос о сценариях, в которых нам будет разрешено их использовать, мы часто получаем простой ответ «Никогда :)».
У меня есть три причины последовать совету…
Никогда не следует делать личные части общедоступными ›.‹
Это просто, методы получения и установки опасны по той же причине, что и публичные поля. Они обеспечивают внешний доступ к деталям реализации. Одним из основных принципов ООП является Инкапсуляция, и поэтому мы можем утверждать, что код, который сильно или неуместно зависит от геттера/сеттера, не является объектно-ориентированным.
Принцип Закона Деметры гласит, что модуль не должен знать о внутренних деталях объектов, которыми он манипулирует. Это означает, что модуль или другой объект не должен знать о внутренней работе других объектов. Методы получения/установки позволяют нам заглянуть внутрь функционирования объекта. Вуаля! нарушен очередной закон.
Поток прервался!
Отсутствие методов получения/установки не означает, что некоторые данные не проходят через систему. На самом деле это простой выход. Всякий раз, когда вы находитесь на распутье и испытываете искушение использовать методы получения/установки, всегда спрашивайте себя, что вместо того, чтобы запрашивать эту информацию, могу ли я указать объекту, что делать вместо этого, и решить проблему? Рассказывайте, а не спрашивайте! Лучше всего свести к минимуму перемещение данных и ограничить последствия изменения одним определением класса. Это значительно упрощает поддержку кода.
Бери, ставь, забудь :)
Методы получения/установки очень просты в использовании и легко забываются. Абсолютно худший сценарий — писать такие методы, думая, что вам может понадобиться доступ к данным в будущем. Прежде всего, нам это не понадобится, а если и понадобится, то мы придумаем лучший способ решить эту проблему, когда придет время. Но до тех пор зачем тратить время на написание и поддержку бесполезного кода? Представьте себе рябь, эти хитрые методы могут действовать как центральная точка для ряби, которая приводит к избыточной информации, путешествующей по всему коду. Опять же, это кричит о кошмаре обслуживания.
Подведение итогов
Дебаты если и не о том, чтобы никогда не использовать геттеры и сеттеры, то об использовании их в крайнем случае. Процесс мышления — самая важная часть здесь, и именно его ниндзя-программисты хотят, чтобы мы изменили. Мы пишем такие методы в силу привычки или это абсолютная необходимость? Мы можем не всегда это видеть, но мы можем устранить большую часть перемещения данных и написать чистый, поддерживаемый код.
