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

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

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

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

Saboteur,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Saboteur,

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

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

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

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

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

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

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