JavaRush /Java блог /Random UA /Геттери та порушена інкапсуляція
Vadelic
14 рівень
Пасадена

Геттери та порушена інкапсуляція

Стаття з групи Random UA
Вирішуючи завдання, я зіткнувся з несподіваною поведінкою гетерів. У тутешніх лекціях і навіть у генерованих 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 існує чудовий метод , який видає read-only колекцію. Це накладає ряд інших обмежень, наприклад, неможливість сортування, але цей випадок у цьому класі є: unmodifiableSortedSet unmodifiableSortedMap і ще кілька, для більшої зручності. public static Collection unmodifiableCollection(Collection c)
Коментарі
ЩОБ ПОДИВИТИСЯ ВСІ КОМЕНТАРІ АБО ЗАЛИШИТИ КОМЕНТАР,
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ