Всегда ли нужно писать геттеры?

Question

[beduin01]

Когда лучше обращаться к полям класса напрямую?

Comments

[Foggy Finder]

напрямую обращаться к полям лучше внутри класса

[#]

Foggy Finder, это точно вредный совет

[Foggy Finder]

#, вредный совет по причине?

[#]

Foggy Finder,

вредный совет по причине

если логика геттеров/сеттеров не тривиальна (тупое присвоение), надо очень хорошо понимать когда можно на прямую что то писать/читать, и если логика действительно есть, надежнее всегда ее использовать

[Foggy Finder]

#, согласен, мне следовало написать более подробный комментарий. Нельзя рассмотреть все случаи, конечно, но необходимо уточнить что я имел ввиду:

beduin01

1. Поля класса снаружи не должны быть доступны для прямого изменению.
2. Если класс реализует INPC, или другие интерфейсы которые завязаны на изменения свойств, то нужно крайне осторожно обновлять поле напрямую в самом классе.
3. WPF и скорее всего другие фреймверки не поддерживают привязку к полям - это следует учитывать.
4. Нужно понимать что такое свойства и во что они разворачиваются компилятором чтобы не попасться в ловушки.
5. Как написал mindtester выше если свойства содержат валидацию или не очевидную логику лучше использовать именно их даже внутри класса.

Пункты выше не более чем рекомендация, а не строгое правило.

Совет - набейте шишки на ошибках в пет проектах, если не уверены как правильно поступить.

Answer 1

[Saboteur]

Читайте что такое инкапсуляция и зачем она нужна.

Внутри класса обращайтесь напрямую. Снаружи класса - принято обращаться через геттеры/сеттеры - чтобы если вдруг вы будете что-то внутри класса менять, вам не нужно было искать где используется ваш класс и как исправить все эти вызовы - вы просто поправите геттер/сеттер в вашем классе.

Comments

[Griboks]

Или просто заменить int x на int x {get;}

[Saboteur]

Евгений Ромашкан, Евгений, инкапсуляция не нарушается, потому что суть геттеров и сеттеров - именно в том, что это публичные методы для доступа к данным, и по сути они ничем не отличаются от других публичных методов, которые мы дергаем из класса.

В случае чего, всегда можно геттер/сеттер переписать на более сложную логику.
А использовать локальные переменные класса для хранения данных - это уже другой вопрос.

[Евгений Ромашкан]

Saboteur,

доступа к данным

Конкретно в этом месте нарушается.

они ничем не отличаются от других публичных методов, которые мы дергаем из класса.

Отличаются. Вышеописанным поведением. Даже сама концепция аксессоров о том что они отдают конкретное поле.
Ну и, конечно, Tell Don't ask

В случае чего, всегда можно геттер/сеттер переписать на более сложную логику.

1. Часто вы такое видите? Теоретически то оно, можно что угодно понаписать, а потом переписать.
2. Что бы вы в геттер не написали, он продолжит возвращать поле из объекта, а если он этого не делает то это не геттер а просто плохо названный метод.

[Saboteur]

Евгений Ромашкан,

Что бы вы в геттер не написали, он продолжит возвращать поле из объекта, а если он этого не делает то это не геттер а просто плохо названный метод.

Нет. Когда кто-то дергает ваш сеттер, вы понятия не имеете какие данные пытаются туда положить. Следовательно в сеттере вы можете провести предварительную валидацию, вдобавок добавить какие-нить метрики, счетчики, любые другие действия, и уже потом присвоить значение. При этом метод останется сеттером.
Тоже и про геттер.

Ну и да, мы можем сделать из геттера плохо названный метод, но сохранить совместимость, позволяя делать рефакторинг продукта по частям, с нормальным приоритетом.
Например перевели продукт с int на long, добавили еще два геттера/сеттера, и начинаем переписывать компоненты на работу с новыми class_getlong_variable, а старые геттеры/сеттеры подправили чтобы они конвертировали long в int и компоненты, которые еще не переехали - работают уже с измененными геттерами.

Общие рекомендации относятся к тенденции, к тому как нужно проектировать. То есть создавать int поля и делать long геттеры - глупо и неправильно. Но если изначально были геттеры и сеттеры, как рекомендовалось, и наступил вышеописанный случай переезда из инт в лонг - это как раз то, для чего геттеры и сеттеры были придуманы, и это сэкономит компании много денег и упростит рефакторинг крупного продукта.

[#]

Внутри класса обращайтесь нлорлорлор ... если вдруг вы будете что-то внутри класса менять, вам не нужно было искать где используется ваш класс и как исправить все эти вызовы - вы просто поправите геттер/сеттер в вашем классе.

1 - все таки, если нет и тени намеков, что потребуется обработка в гет/сет - в них и нет нужды.
2 - если есть хотя бы в замыслах (даже если руки ни когда и не дойдут) - внутри класса тоже следует использовать геттеры/сеттеры
3 - путь джедая - ясно понять суть инструмента и правила его использования )))... но и джедаи делают ошибки )))
ps .. а ошибки истинных джедаев могут и стоить весьма дорого

[Saboteur]

1 - все таки, если нет и тени намеков, что потребуется обработка в гет/сет - в них и нет нужды.

Если у класса есть методы, и все внешние клиенты пользуются только методами, то да - в геттерах и сеттерах нет нужды. Я об этом и говорил с самого начала.

Внутри класса нет смысла использовать геттеры и сеттеры. Поскольку предполагается, что это публичные, а не приватные методы. Если вы используете их только внутри, то это уже скорее валидаторы.

[#]

Saboteur,

Если вы используете их только внутри,

я бы сказал и внутри тоже

то это уже скорее валидаторы

да, возможно валидаторы, но еще естественнее триггеры ))

если ни то, ни другое точно не требуется, то проще отставить просто паблик поле ))

ps а вот в случае триггеров - что вне классса, что внутри, только через геттерры/сеттеры... (хотя джедаю всегда виднее ))

pss простой пример - аудит доступа.. или логирование.. как то так

Answer 2

[nApoBo3]

ИМХО сейчас данная "концепция" уже устарела и не очень актуальна.
Во-первых сейчас не смешивают модели и логику в одном классе, по этому в большинстве случаев геттеры и сеттеры остаются пустыми.
Во-вторых рефлексия запросто инкапсуляцию нарушает.
В-третьих в ide есть средства рефакторинга которые снимают проблему изменения полей.
Так что скорее это привычка и традиция, я очень редко вижу геттеры и сеттеры с кодом.

Answer 3

[Молзв Реках]

Желательно конечно всегда... Это закон инкапсуляции, нежелательно если бы какой то рандомный человек изменил поле в вашем классе. Так что это по вашему усмотрению, когда у мея были маленькие знания языков, я тоже думал - "зачем это ООП? Зачем инкапсуляция вообще бред", а сейчас я понимаю зачем оно. Просто учитесь и в ходе изучения как и я поймёте всё. Ответ на ваш вопрос - надо. Геттеры и сеттеры всегда нужны. Это как ловить ошибки. (try, except)