Подскажите насчет инкапсуляции.

Читаю лекцию по инкапсуляции. https://javarush.com/groups/posts/1928-getterih-i-setterih Там рассматриваються примеры с геттерами и сеттерами, которые защищают от создания некорректных полей, например кота возрастом +1000 лет) При этом в примере кода остается паблик конструктор, который позволит создать того же кота возрастом -1000 лет, несмотря на сеттеры и гетеры. Это недостаток статьи или я чего то недопонял?

public class Cat {

   private String name;
   private int age;
   private int weight;

   public Cat(String name, int age, int weight) {
       this.name = name;
       this.age = age;
       this.weight = weight;
   }

   public Cat() {
   }

   public void sayMeow() {
       System.out.println("Мяу!");
   }

   public String getName() {
       return name;
   }

   public void setName(String name) {
       this.name = name;
   }

   public int getAge() {
       return age;
   }

   public void setAge(int age) {
       this.age = age;
   }

   public int getWeight() {
       return weight;
   }

   public void setWeight(int weight) {
       this.weight = weight;
   }
}

Комментарии (6)

популярные
новые
старые

Для того, чтобы оставить комментарий Вы должны авторизоваться

Настя Иванова Backend Developer

9 марта, 21:53

все эти разговоры про инкапсуляцию чаще всего остаются на уровне теории. из практических аспектов - приватные поля нужны как защита от дурака, чтобы пользователь объекта класса не менял состояние на прямую. геттеры и сеттеры это скорее каргокульт который уже закрепился. в большинстве случаев геттеры и сеттеры не защищают от чего либо. но зачастую требуются если работаешь с внешними либами которые могут парсить твой объект через рефлексию. ну и все же если говорить про "реальную защиту" то есть случаи когда какой нибудь бармалей смог подгрузить джарник внутри jvm который позволит прочитать все объекты и если тут все поля сделать публичными то данные утекут - но и этот пример притянут за уши тк если кто то что то ворует то проще своровать снэпшот самой JVM со всеми данными и там никакие геттеры не спасут. ну и стоит обратить внимание на саму JDK где на все эти getter/setter клали большой болт (особенно первые версии).

-4

Уровень 21

5 марта, 15:38

имхо. Как я понял, то в целом конструктор и сеттеры это просто прослойка между полем и тем кто хочет полю что то назначить. Инкапсуляция, что значит само это слово? - хранение в себе / прятать данные. Но в целом не обязано как то охранять их, вот это валидирование данных уже больше к понятию 'изоляция' относится, где в целом в ООП инкапсуляция параллельно включает в себе и изоляцию, потому и параллельно инкапсулированию данных обсуждают и валидирование. Геттеры, сеттеры это как приборная панель накрывающая провода какого нибудь механизма, где можно этот механизм привести в действие и без приборной панели, лишь соединив вручную проводки, грубо говоря, так же и с полем, ему можно назначить значение на прямую, а можно через конструктор, а можно через сеттер, а можно через фабричный метод, или билдер или или ... параллельно рассматривая нужна ли там какая нибудь валлидация.

Olexandr

Уровень 29

6 марта, 10:19

Ну да, все правильно. И в данном примере мы видим некую "уязвимость", которую забыли закрыть

Денис Enterprise Java Developer

6 марта, 14:35

Как уже многие высказались, инкапсуляция это сокрытие реализации. Ты, как разработчик, ограничиваешь доступ к каким-либо частям кода, или совсем или выставив определённый набор методов по взаимодействию с этими кусками кода. Можно назвать этот набор методов интерфейсом. Если бы садишься в машину, у тебя есть руль, руль и педали, что является интерфейсом, но ты понятия не имеешь как устроено рулевое управление, или как именно педали делают впрыск бензина больше или прожимают торомоза. Так что можно сказать что механизм управления автомобилем инкапсулирован, но у тебя есть четко заданный сценарий работы с ним. А вязаться к конкретным примерам или реализациям в коде не стоит. В коде могут быть ошибки, что-то могло устареть, автор мог не точно выразить свою мысль. Твоя задача понимать концепцию :)

Aleksei Software Engineer в Cisco

Expert

4 марта, 18:02

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

public Cat(String name, int age, int weight) {
    if (isValidAge(age) && isValidWeight(weight)) {
        this.name = name;
        this.age = age;
        this.weight = weight;
    } else {
        log.error("Ошибка! Некорректные данные при создании объекта Cat.");
    }
}

private boolean isValidAge(int age) {
    return age >= 0;
}

private boolean isValidWeight(int weight) {
    return weight >= 0;
}

Еще можно использовать сеттеры в конструкторе, но это считается не очень хорошей практикой:

public Cat(String name, int age, int weight) {
    setName(name);
    setAge(age);
    setWeight(weight);
}

Di Ma Java Developer в Сбер

4 марта, 16:23

В документации Оракл для 8 джавы: абстрактно инкапсуляцию объясняю так (на примере моделирования объектов - основа ООП): Допустим есть собака (объект унаследовавший некоторые методы от млекопитающих) и есть у него свойство количество еды в желудке. Прямо повлиять на это свойство мы не можем (набить желудок собаки миную физиологические процессы), т.е. количество еды в желудке инкапсулированно в собаке. Но мы можем заставить собаку исполнить метод - дать пожрать, который изменит состояние собаки( свойство наполненности желудка). В твоем примере есть конструктор, который получает необходимые вводные параметры, их кстати можно в том же конструкторе валидировать. Допустим хочешь ты создать 1000 летнего кота, но в конструкторе есть условие, что кот будет максимум 5 летним или минимум 1 летним. И вот что бы ты не набирал у тебя получится здоровый кот, которого принудительно потом состарить не получится.