Решая задачи, я столкнулся с неожиданным поведением геттеров. В здешних лекциях и даже в генерируемых IntelliJ IDEA геттерах используется простейшая схема:
public final class A {
private A field;
public A getField() {
return field;
}
public void setField(A field) {
this.field = field;
}
}
Если поле примитивного типа или String, которые передаются по значению, то всё в порядке, но если объект передаётся по ссылке, то получается, что через геттер можно получить полный доступ к полю, что сводит на нет установленный уровень доступа protected.
Если в сеттере стоит какое-либо условие валидности, то через такой геттер его можно обойти, что нарушает инкапсуляцию и правильно было бы создавать клон объекта, что бы избежать этой неприятности.
Понимаю, что не все объекты просто клонировать и если это отдаётся на ответственность программиста, то странно почему об этом нигде в лекциях не встречалось упоминаний.
UPD:
Геттер, как идея, конечно же, не нарушает инкапсуляцию, но написан он должен быть так, что бы не предать принципов ООП. Это значит, что если геттер выдаёт объект, то таким образом, что бы пользователь не смог его изменить никаким другим способом, который прописан в классе.
В классе Collections существует замечательный метод public static Collection unmodifiableCollection(Collection c)
который выдаёт read-only коллекцию.
Это накладывает ряд других ограничений, например, невозможность сортировки, но на этот случай в этом классе есть:
unmodifiableSortedSet
unmodifiableSortedMap
и ещё несколько, для большего удобства.
0
Комментарии (35)
популярные
новые
старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Не совсем понял, в чем нарушается инкапсуляция?
Вы получаете геттером ссылку на экземпляр класса А. Класс А тоже имеет внутреннюю структуру, разные модификаторы доступа… Скажем, доступа к приватным полям класса А вы не получаете через геттер. Все норм… Геттер просто возвращает ссылку на значение в поле А… Что не так? В чем противоречие?
Если бы всё было в А скрыто — то какой толк в такой ссылке? Как с ней работать?
В том то и дело, что объект передаётся геттером по ссылке и полученный объект можно изменить из-за чего изменится и объект(ведь эти две ссылки указывают на один и тот же объект в хиппе), на который ссылается field.
Вот например такой код:
class A{
public static void main(String[] args) {
System.out.println("Original: " + B.getList());
ArrayList<String> edit = B.getList();
edit.add("two");
System.out.println("Changed: " + B.getList());
edit = B.getListSafe();
edit.add("three");
System.out.println("Not changed(safe Getter): " + B.getList());
}
}
class B {
private static ArrayList<String> list = new ArrayList<>();
static {
list.add("one");
}
public static ArrayList<String> getList() {
return list;
}
public static ArrayList<String> getListSafe() {
return new ArrayList(list);
}
}
Вывод будет таким:
Original: [one]
Changed: [one, two]
Not changed(safe Getter): [one, two]
Я понимаю инкапсуляцию как в первую очередь сокрытие реализации. Т.е. внешний пользователь класса (например другой программист) должен иметь доступ к тем методам и данным класса, которые можно безопасно менять, не боясь все сломать. Метод приватным объявляется не для того, что бы от кого-то что-то спрятать — а для того, что бы в первую очередь сказать — вот тебе игрушка, из неё торчат лапки, ушки и кой-чё ещё… За это можно дергать, а в кишках ковыряться не надо — можно сломать. Вдруг я решу в следующей версии избавиться от одних внутренностей и добавить новые? А публичные методы я уже менять не буду. И пользователь класса этого даже не заметит. Хотя как указал коллега выше, если сильно надо, то поковыряться в кишках можно. Но это уже на свой страх и риск с помощью спецсредств.
Всё верно, только через такой геттер, который дарует ссылку на объект, можно сломать.
Если в классе есть какой-то список, который нельзя пользователю класса менять, но есть геттер, как на примере выше, то через полученную таким геттером ссылку можно изменить этот список.
ПС: Пример тестил?
Что значит сломать список? Если там список «который нельзя менять», возможно вам не нужен геттер в таком виде, возможно вообще пользователю класса не нужен список, или непосредственный доступ к списку.
Короче, не вижу проблемы…
Давайте только необходимый доступ…
И в конце поста я предполагаю, что достаточно написать более безопасный геттер, но меня изумляет, что тут в примерах методично используют вот такие небезопасные геттеры и ни разу эта ситуация не комментировалась в лекциях
Так можно сломать… Согласен. Но! Я бы «setField» тогда переименовал бы в «add» (а то сбивает с толку), и задался бы вопросом — а зачем пользователю мой список? Что он будет с ним делать? Если всё что угодно, и это может сломать мой класс — то возможно надо не ArrayList? А применить паттерн Декоратор и нарисовать свой класс MyArrayLisr и в переопределенный метод add (и остальные нужные методы) напихать своих проверок, а ненужные методы закрыть или не переопределять? И внутренний ArrayList сделать приватным? На эту тему кстати есть урок, если ещё не дошли
То что указано в примерах — это ж примеры, они для простоты, особенно на старте… Не будьте так уж строги
что бы обезопасить данный пример, достаточно написать
return new ArrayList(Field)
Тут очень хорошие примеры, странно что к такому важному моменту не уделено должного внимания.
Возможно что на практике всё не так как в учебке, но это ещё только предстоит узнать.
К размышлению подтолкнула одна задача, в которой надо было изменить поле через полученную ссылку геттером, что, как мне кажется, не совсем адекватно.
если ты пишешь геттер к полю, значит ты уже отрываешь доступ к полю сам. Значит в твоей реализации предположено менять список. Если менять его не хочешь то не пишешь гетер и поле остается закрытое. Без инкапсуляции как ты закроешь поле? Вот если нет модификаторов доступа (нет реализации в ЯП), как тогда?
В примерах геттеры в 100% случаев (минус одна задача) используется исключительно для того, что бы прочесть данные, а доступ к полю предоставляется полный, в том числе и для редактирования.
Такое впечатление, что это получается как побочный результат, побочный и вредный.
Думаю, что правильный вариант — написать такую реализацию геттера, что бы и память не сожрать и не предать принципов ООП. А в таком геттере я вообще не вижу особого смысла, можно просто пабликом объявит
Можно… Просто вы поймите… У вас список. Ну закрыли вы его… Даже скопировали! Но в списке объекты… Возможно какие-то классы… Их тоже будете копировать? А там могут быть свои ссылки! Выходит вообще утопия, потому что по факту так никто не делает! Значит надо проектировать класс без геттера, а что бы он давал те интрументы по работе с вашим приватным списком, которые нужны. Надеюсь, тема закрыта.
Если ты про 5 — ый уровень, то тут рассказывают о том что такое геттер и сеттер, и как им пользоваться. О инкапсуляции расскажут тебе в 11 — ом уровне более детально. Информацию надо подавать порционно.
который действует как в Си final — выдаёт read-only коллекцию. Это накладывает ряд других ограничений, например( на этот случай есть unmodifiableSortedSet unmodifiableSortedMap), невозможность сортировки, но полностью сохраняет инкапсуляцию класса.
Открою тебе маленький секрет, даже к приватным полям можно получить доступ, и поменять значение, без геттеров и сеттеров, и даже можно поменять адрес в памяти.
Не мог бы ты более аргументировано развернуто каментить?))
Почему ты считаешь, что нет? С таким успехом можно оставить поле public и не создавать геттеры и сеттеры.
Инкапсуляция означает, что данные объекта недоступны его клиентам непосредственно. Вместо этого они инкапсулируются — скрываются от прямого доступа извне. Инкапсуляция предохраняет данные объекта от нежелательного доступа, позволяя объекту самому управлять доступом к своим данным.
Ну если ты создал геттеры и сеттеры то ты даешь доступ сам к полям (косвенный), не напрямую. и в этих методах можешь сделать себе нужные проверки. Да и методы можешь сделать не только публичные.
Так в данном случае не происходит никакого предохранения. Если в сеттере могу быть проверки, то через полученную ссылку на объект геттером его можно менять в обход проверок установленных в сеттере.
Геттер, который передаёт объект по значению не представляет опасности для инкапсуляции, но геттер передающий объект по ссылке — это же нарушение её.
В джаве по значению передаются только примитивные типы и String.
Мне интересно что думают на этот счёт знатоки, учитывая что тут в задачах очень часто используются геттеры, которые выдают ссылки на приватные поля. У меня есть предположение, почему ИДЕА генерирует такие геттеры (в конце поста написал) но удивляет, что в здешних лекциях про это ни слова не было.
Повторяю тебе ещё раз, в джаве всегда передается по значению. Почитай спеку по JVM, если мне не веришь. Или хотя бы то что я тебе скинул. Если ты спрашиваешь у других, и при этом не принимаешь информацию, тогда зачем создавать тему?
Ссылки, указатели, значения — терминология в джаве несколько нарушена от других языков и я использую терминологию Си.
Не хотелось бы спорить по терминам.
«По ссылке» я подразумеваю передачу указателя на объект в хиппе:
public class A {
private static ArrayList<Integer> field = new ArrayList<>();
public static void main(String[] args) {
ArrayList<Integer> test = getField();
test.add(1);
System.out.println(field);
}
static ArrayList<Integer> getField(){
return field;
}
}
В джаве:
MyClass myClass;
тоже самое что в СИ:
MyClass *myClass;
Указателей в джаве нет. Таких как в Си
Ссылки в джаве в каком то частном случае являюся указателями (Как в С). Но в си указатели всегда занимают 4 байта, и по сути это всегда инт, и в своей середине имеет адрес памяти куда ссылается.
В джаве там совсем по другому.
В джаве при передаче обьекта в метод как параметр, создается новая ссылка что указывает на тот же обьект, таким образом происходит передача по значению обьектов. Ссылки разные, обьект один и тот же.
Вы получаете геттером ссылку на экземпляр класса А. Класс А тоже имеет внутреннюю структуру, разные модификаторы доступа… Скажем, доступа к приватным полям класса А вы не получаете через геттер. Все норм… Геттер просто возвращает ссылку на значение в поле А… Что не так? В чем противоречие?
Если бы всё было в А скрыто — то какой толк в такой ссылке? Как с ней работать?
Вот например такой код:
Вывод будет таким:
Original: [one]
Changed: [one, two]
Not changed(safe Getter): [one, two]
Если в классе есть какой-то список, который нельзя пользователю класса менять, но есть геттер, как на примере выше, то через полученную таким геттером ссылку можно изменить этот список.
ПС: Пример тестил?
Короче, не вижу проблемы…
Давайте только необходимый доступ…
Но при таком геттере вполне возможно:
ArrayListtest = detField();
test.add(0);
И в конце поста я предполагаю, что достаточно написать более безопасный геттер, но меня изумляет, что тут в примерах методично используют вот такие небезопасные геттеры и ни разу эта ситуация не комментировалась в лекциях
То что указано в примерах — это ж примеры, они для простоты, особенно на старте… Не будьте так уж строги
return new ArrayList(Field)
Тут очень хорошие примеры, странно что к такому важному моменту не уделено должного внимания.
Возможно что на практике всё не так как в учебке, но это ещё только предстоит узнать.
К размышлению подтолкнула одна задача, в которой надо было изменить поле через полученную ссылку геттером, что, как мне кажется, не совсем адекватно.
Такое впечатление, что это получается как побочный результат, побочный и вредный.
+1 короче
аргументированоразвернуто каментить?))Почему ты считаешь, что нет? С таким успехом можно оставить поле public и не создавать геттеры и сеттеры.
Ну если ты создал геттеры и сеттеры то ты даешь доступ сам к полям (косвенный), не напрямую. и в этих методах можешь сделать себе нужные проверки. Да и методы можешь сделать не только публичные.
Геттер, который передаёт объект по значению не представляет опасности для инкапсуляции, но геттер передающий объект по ссылке — это же нарушение её.
Нужен или нет, ты сам решаешь, точно также реализацию. Главное чтобы не было прямого доступа к полям. А что открывать через методы, решаешь уже ты.
Мне интересно что думают на этот счёт знатоки, учитывая что тут в задачах очень часто используются геттеры, которые выдают ссылки на приватные поля. У меня есть предположение, почему ИДЕА генерирует такие геттеры (в конце поста написал) но удивляет, что в здешних лекциях про это ни слова не было.
Не хотелось бы спорить по терминам.
«По ссылке» я подразумеваю передачу указателя на объект в хиппе:
В джаве:
MyClass myClass;
тоже самое что в СИ:
MyClass *myClass;
Ссылки в джаве в каком то частном случае являюся указателями (Как в С). Но в си указатели всегда занимают 4 байта, и по сути это всегда инт, и в своей середине имеет адрес памяти куда ссылается.
В джаве там совсем по другому.
В джаве при передаче обьекта в метод как параметр, создается новая ссылка что указывает на тот же обьект, таким образом происходит передача по значению обьектов. Ссылки разные, обьект один и тот же.
Вернёмся к сабжу:
В примере метод editField() добавляет в список field неверный элемент «0».