Публичные поля в объекте передачи данных

Question

В мои годы программирования я часто делал классы, которые просто группировали несколько переменных со своими сеттерами и геттерами. Я видел такие типы объектов, которые называются объектами ценности, объектами домена или объектами модели в зависимости от контекста, в котором они используются. Наиболее подходящим термином для общего использования, по-видимому, является объект передачи данных (DTO). Это описывает POJO, который содержит только аксессоры и мутаторы.

Я только что написал один такой объект, который содержит около пятидесяти полей, используемых для установки параметров темы на диаграмме. Теперь мне интересно, если вместо того, чтобы генерировать сотни геттеров и сеттеров, я должен просто объявить эти поля общедоступными. Это противоречит всему, что мне подсказывают мои инстинкты программирования, но я не могу отрицать, что это значительно увеличит удобочитаемость моего кода и уменьшит количество кода шаблона в классе.

Единственная причина, по которой я могу видеть , а не, использовать общедоступные поля, если мне нужно выполнить какие-либо проверки в этих полях. Если мы предположим, что проверка типа достаточна для моих целей, использует общедоступные поля в этом сценарии приемлемый разрыв с объектно-ориентированным дизайном? Будет ли публичный DTO лучше работать в крупных пакетных операциях?

Answer 1

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

Основная причина использования комбинации геттер/сеттер вместо открытого поля заключается в том, что вы можете изменить определение. Итак, если ваш DTO является частью интерфейса между компонентами, лучше всего использовать геттеры. Если вы измените внутреннюю работу, вы можете адаптировать геттер для имитации старого поведения и поддержания совместимости.

Другая причина в том, что вы можете создавать поля только для чтения. Часто для DTO, доступный только для чтения и неизменный, является хорошим выбором.

Третья причина может заключаться в том, что ваш DTO должен быть javabean, потому что вы намерены использовать его в каком-то инструменте, который его требует.

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

Не стоит ожидать большой разницы производительности, хотя :)

Answer 2

Я не считаю это ужасно плохой практикой, чтобы иметь класс «настройки» или «тема» или «стиль» с общедоступными атрибутами.

Современные IDE с инструментами рефакторинга делают тривиальным продвигать атрибут getter/setter, если вы хотите выполнять сложные вычисления или проверять значения в заданное время.

Часто в вашем «setTheme» или любой другой функции, которая использует эти классы настроек, является хорошим чистым местом для проверки.

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