зачем нужны геттеры и сеттеры java
Есть два типа свойств объекта.
Первый тип это свойства-данные (data properties). Мы уже знаем, как работать с ними. Все свойства, которые мы использовали до текущего момента, были свойствами-данными.
Второй тип свойств мы ещё не рассматривали. Это свойства-аксессоры (accessor properties). По своей сути это функции, которые используются для присвоения и получения значения, но во внешнем коде они выглядят как обычные свойства объекта.
Геттеры и сеттеры
Свойства-аксессоры представлены методами: «геттер» – для чтения и «сеттер» – для записи. При литеральном объявлении объекта они обозначаются get и set :
Геттер срабатывает, когда obj.propName читается, сеттер – когда значение присваивается.
Например, у нас есть объект user со свойствами name и surname :
Снаружи свойство-аксессор выглядит как обычное свойство. В этом и заключается смысл свойств-аксессоров. Мы не вызываем user.fullName как функцию, а читаем как обычное свойство: геттер выполнит всю работу за кулисами.
Давайте исправим это, добавив сеттер для user.fullName :
Дескрипторы свойств доступа
Дескрипторы свойств-аксессоров отличаются от «обычных» свойств-данных.
То есть, дескриптор аксессора может иметь:
Например, для создания аксессора fullName при помощи defineProperty мы можем передать дескриптор с использованием get и set :
Ещё раз заметим, что свойство объекта может быть либо свойством-аксессором (с методами get/set ), либо свойством-данным (со значением value ).
Умные геттеры/сеттеры
Геттеры/сеттеры можно использовать как обёртки над «реальными» значениями свойств, чтобы получить больше контроля над операциями с ними.
Использование для совместимости
У аксессоров есть интересная область применения – они позволяют в любой момент взять «обычное» свойство и изменить его поведение, поменяв на геттер и сеттер.
Давайте его сохраним.
Добавление геттера для age решит проблему:
Теперь старый код тоже работает, и у нас есть отличное дополнительное свойство!
Java-Lombok: нужны ли геттеры и сеттеры?
Привет всем энтузиастам Java! Давайте поговорим о Java и рефакторинге. Как известно, Java остается одним из наиболее популярным языком программирования. В каждом новом релизе добавляется все больше фич, с которыми он превращается в идеальное сочетание элементов объектно-ориентированного и функционального языка с введением лямбда-выражений, стримов и CompletableFuture в Java 8.
Всем нам знакомы Java-бины, они же POJO (plain old java objects, “старые-добрые Java-объекты”), они же DTO (data transfer objects, “объекты передачи данных”). Даже несмотря на то, что в обширном Java-сообществе нет согласия по поводу определений, соответствующих каждому из понятий, все они делают примерно то же самое. Названия разные, концепция одна.
Примечание: в этой статье я буду использовать термин DTO для Java-бинов.
Общие черты DTO:
Подводя итог, DTO — это кастомизируемые типы данных, а вышеописанное соглашение — всего лишь условность, которая не является стандартом Java и паттерном проектирования. Впрочем, в конечном счете, паттерн проектирования— это наилучшая практика, доказавшая свою эффективность в решении реальных задач.
Однако существует одна проблема. Что, если DTO содержит, скажем, десять свойств или больше? Вот как выглядит типичный DTO.
Десятки геттеров и сеттеров здесь смотрятся не особенно хорошо. Разумеется, это один из примеров плохо читаемого спагетти-кода. Представьте, что у вас есть десятки или даже сотни таких DTO вместе с геттерами и сеттерами для каждого из них. Для решения этой проблемы есть элегантный способ, позволяющий достичь того же самого результата с менее шаблонным кодом.
Как Lombok работает за кадром:
Lombok уменьшает шаблонность посредством аннотаций, которые выполняют преобразование классов во время компиляции. Lombok уже поставляется с приличным набором преобразований, но вы также можете создать свои собственные пользовательские преобразования.
Lombok действует как процессор аннотаций, который играет роль диспетчера, делегирующего функции обработчикам аннотаций Lombok (это то, что мы собираемся создать). Обработчики обнаруживаются с помощью фреймворка под названием SPI. Обработчики аннотаций Lombok объявляют конкретную аннотацию, которую они обрабатывают. При делегировании полномочий обработчику процессор аннотаций Lombok обеспечивает объект, представляющий абстрактное синтаксическое дерево (AST) аннотируемого узла (например: класс, метод, поле и т. д.). Обработчик аннотаций Lombok может свободно изменять AST, вводя новые узлы: методы, поля и выражения. После этапа обработки аннотаций компилятор будет генерировать байт-код уже из модифицированного AST.
Вкратце, Lombok не генерирует код. Вместо этого он использует неопределенные и недокументированные внутренние вызовы API реализации компилятора для непосредственного изменения абстрактного синтаксического дерева программы в промежутке между чтением исходного кода и выводом скомпилированного байт-кода.
Отставим теорию. Давайте посмотрим, как быстро получится ввести Lombok в наш проект Java. maven—зависимость выглядит так:
Аннотации @Getter и @Setter применяются ко всему классу, как показано ниже:
2. Геттеры и сеттеры Lombok для применения избирательно в заданном DTO:
В случае если нам нужны геттеры и сеттеры только для определенных переменных/свойств, мы можем добиться и этого тоже:
3. Lombok для замены конструкторов:
а) Замена конструктора all-args
Иногда раскрывать методы-сеттеры не нужно и от клиента требуется устанавливать значения только через вызов конструктора.
Пример Java DTO с конструктором all-args (без использования Lombok ):
После замены конструктора all-args в приведенном выше фрагменте кода аннотацией @AllArgsConstructor он, по существу, сводится к чему-то вроде этого:
б) Замена конструктора no-args
И c заменой конструктора no-args всё точно так же:
в) Добавление спецификаторов доступа к конструкторам
4. Lombok для генерации методов toString():
Результат выглядит так:
5. Lombok для генерации методов equals() и hashCode():
Это то же самое, что и задействовать все аннотации, перечисленные в приведенном ниже фрагменте кода:
В проекте Lombok доступны и другие аннотации/утилиты, которые очень полезны и удобны.
Очень легко рефакторить существующий код/проект и вводить туда Lombok со значительно меньшими усилиями и без поломок. Как уже упоминалось ранее, код становится намного чище, проще и элегантнее.
Добавление плагина Lombok в IDE
Примечание: если вы используете Eclipse или IntelliJ, простое добавление зависимости Lombok в pom.xml не всегда срабатывает, и плагин Lombok необходимо добавлять вручную (в зависимости от вашей IDE).
Добавление плагина Lombok в IntelliJ.
Добавление плагина Lombok в Eclypse
В некоторых случаях вам, возможно, придется переключиться на публичное подключение wi-fi вашей организации, чтобы иметь возможность искать и устанавливать плагины.
Если вы подключены к VPN, попробуйте отключиться от него и после этого добавить плагин.
Если вышеперечисленные приемы не сработают, измените настройки прокси-сервера в IDE и попробуйте добавить плагин еще раз.
Геттеры и сеттеры в Javascript
Javascript — очень изящный язык с кучей интересных возможностей. Большинство из этих возможностей скрыты одним неприятным фактором — Internet Explorer’ом и другим дерьмом, с которым нам приходится работать. Тем не менее, с приходом мобильных телефонов с актуальными браузерами и серверного JavaScript с нормальными движками эти возможности уже можно и нужно использовать прям сейчас. Но по привычке, даже при программировании для node.js мы стараемся писать так, чтобы оно работало в IE6+.
В этой статье я расскажу про интересный и не секретный способ указывать изящные геттеры и сеттеры и немножко покопаемся в исходниках Mootools. Частично это информация взята из статьи John Resig, частично лично мой опыт и эксперименты.
Стандартные геттеры
Что такое Геттеры и Сеттеры, надеюсь знают все. Обычно и кроссбраузерно это выглядит так:
Можно пойти дальше и написать более изящный вариант:
Нативные геттеры/сеттеры
Но есть более удобный способ, который работает во всех серверных движках и современных браузерах, а именно Firefox, Chrome, Safari3+, Opera9.5+ — задание сеттера и геттера для свойства так, чтобы продолжать обращатся к свойству, как свойству. У такого подхода есть несколько преимуществ:
1. Более изящная запись. Представим ORM:
2. Если апи, которое базируется на свойствах уже есть и его нельзя менять (а очень нужно).
Есть два способа задать такой геттер/сеттер:
Через объект:
Через методы __defineGetter__ и __defineSetter__:
Определяем поддержку браузером
Из этого можно получить лёгкий способ определения, поддерживает ли браузер геттеры или не поддерживает:
Как быть с наследованием?
Таким образом нашему target передадутся не значения родительского source, а функции-геттеры/сеттеры.
Что следует помнить
MooTools
Мутулз не поддерживает по-умолчанию такую возможность. И, хотя я уже предложил патч, мы можем с лёгкостью (слегка изменив исходники) заставить его понимать геттеры и сеттеры.
Итак, какая наша цель?
Более того, в классах унаследованных через Implements и Extends тоже должны работать геттеры и сеттеры родительского класса. Все наши действия будут происходить в файле [name: Class] внутри анонимной функции.
Во-первых, внутри функции, в самом верху, определим функцию, которая перезаписывает только геттеры и сеттеры. И хотя мы отказалась от устаревших браузеров — стоит застраховаться.
Конечно, если наш скрипт с такими геттерами попадёт в устаревший браузер, то он просто упадёт, но это страховка от того, чтобы кто-то случайно не взял этот файл и не прицепил его к себе на сайт, а потом недоумевал, что такое с ишаком.
Мы видим, что если __lookupGetter__ не поддерживается, то функция просто ничего не сделает.
Теперь заставляем работать getterы и setterы во время создания класса и наследования (Extends). Для этого:
Отдельным движением надо реализовать наследование геттеров и сеттеров от примесей (Implements). Для этого надо найти встроенные Мутаторы и добавить всего одну строку:
Все, теперь сеттеры и геттеры реализуются и мы с лёгкостью можем их наследовать и использовать. Наслаждайтесь)
Геттеры и сеттеры
Материал на этой странице устарел, поэтому скрыт из оглавления сайта.
Для управляемого доступа к состоянию объекта используют специальные функции, так называемые «геттеры» и «сеттеры».
Геттер и сеттер для воды
На текущий момент количество воды в кофеварке является публичным свойством waterAmount :
Это немного опасно. Ведь в это свойство можно записать произвольное количество воды, хоть весь мировой океан.
Это ещё ничего, гораздо хуже, что можно наоборот – вылить больше, чем есть:
Так происходит потому, что свойство полностью доступно снаружи.
Чтобы не было таких казусов, нам нужно ограничить контроль над свойством со стороны внешнего кода.
Для лучшего контроля над свойством его делают приватным, а запись значения осуществляется через специальный метод, который называют «сеттер» (setter method).
Теперь waterAmount – внутреннее свойство, его можно записать (через сеттер), но, увы, нельзя прочитать.
Для того, чтобы дать возможность внешнему коду узнать его значение, создадим специальную функцию – «геттер» (getter method).
Единый геттер-сеттер
Для большего удобства иногда делают единый метод, который называется так же, как свойство и отвечает и за запись, и за чтение.
При вызове без параметров такой метод возвращает свойство, а при передаче параметра – назначает его.
Единый геттер-сеттер используется реже, чем две отдельные функции, но в некоторых JavaScript-библиотеках, например jQuery и D3, подобный подход принят на уровне концепта.
Итого
Также можно организовать геттеры/сеттеры для свойства, не меняя структуры кода, через дескрипторы свойств.
Задачи
Написать объект с геттерами и сеттерами
Напишите конструктор User для создания объектов:
Должен работать так:
Обратим внимание, что для «геттера» getFullName нет соответствующего свойства объекта, он конструирует ответ «на лету». Это нормально. Одна из целей существования геттеров/сеттеров – как раз и есть изоляция внутренних свойств объекта, чтобы можно было их как угодно менять, генерировать «на лету», а внешний интерфейс оставался тем же.
Добавить геттер для power
Обратим внимание, что ситуация, когда у свойства power есть геттер, но нет сеттера – вполне обычна.
Здесь это означает, что мощность power можно указать лишь при создании кофеварки и в дальнейшем её можно прочитать, но нельзя изменить.
Добавить публичный метод кофеварке
При этом, конечно же, должны происходить все необходимые проверки – на положительность и превышение ёмкости.
Для чего используются геттеры и сеттеры в Java?
Добрый день! Подскажите, пожалуйста, новичку, для чего используются сеттеры и геттеры в Java?
Суть я понимаю, что они позволяют получать доступ к переменным других классов с уровнем доступа private, но зачем тогда ставить уровень доступа private на переменные, если все равно через геттеры и сеттеры можно их считать из другого класса.
P.S. Сильно не ругайте, только начал осваивать Java.
Простой 1 комментарий
Сильно не ругайте, только начал осваивать Java.
Нет никакого смысла, если нормально программировать и строить простой удобный код. Этакий способ формально соблюсти инкапсуляцию и сокрытие данных: состояние приватное? Приватное 🙂
Чреваты тем, что плодят высокую связанность в коде, состояние и управляется снаружи (на основе геттеров) и контролируются инварианты где угодно и как угодно. По сути превращаем сущности в структуры, но тк это все же бизнес-объекты, а знания бизнес-состояния нужно — то они гуляют по всему проекту и ничем не ограничены. заплетая и заплетая код снова и снова, а также погружая в эти «сущности» все больше и больше знаний.
Доходит до того, что через заказ можно достать товар, через товар можно достать поставщика, через поставщика пользователя с данными аутентификации. и все работает со всем. плодя кучу сервисов и взрывая мозг.
Сеттеры и геттеры нужны для разных манипуляций: валидация, костыльного маппинга, сериализации и десерриализации.
Хорошими и современной практикой сейчас является — не использование и геттеров и сеттеров.
Мои изыскания:
Зачем (не)нужны геттеры?
Геттеры/сеттеры и проблема с инкапсуляцией (примеры на Symfony, аналог Spring в php с аналогичной плохой практикой)