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

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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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