что такое инкапсуляция приведите пример инкапсуляции java
Что такое инкапсуляция в Java?
Инкапсуляция в Java – это принцип объединения данных (переменных) и кода в единое целое. Это одна из четырех концепций ООП. Другие три – это Наследование, Полиморфизм и Абстракция.
Инкапсуляция на примере
Чтобы понять, что такое инкапсуляция, рассмотрим следующий класс банковских счетов с методами депозита и отображения баланса.
Обычно переменные в классе устанавливаются как «частные», как показано ниже. Доступ к нему можно получить только с помощью методов, определенных в классе. Никакой другой класс или объект не может получить к ним доступ.
Если элемент данных является закрытым, это означает, что доступ к нему возможен только в пределах одного класса. Никакой внешний класс не может получить доступ к частному члену данных или переменной другого класса.
Но реализация метода имеет проверку на отрицательные значения. Таким образом, второй подход также терпит неудачу.
Таким образом, вы никогда не подвергаете свои данные внешней стороне. Что делает ваше приложение безопасным.
Весь код можно представить как капсулу, и вы можете общаться только через сообщения. Отсюда и название инкапсуляции.
Сокрытие данных в Java
Часто инкапсуляция Java называется скрытием данных. Но концепция инкапсуляции не просто скрывает данные, она предназначена для лучшего управления или группировки связанных данных.
Чтобы добиться меньшей степени инкапсуляции в Java, вы можете использовать такие модификаторы, как «protected» или «public». Благодаря инкапсуляции разработчики могут легко изменять одну часть кода, не затрагивая другую.
Методы получения и установки в Java
Если элемент данных объявлен как «закрытый», то доступ к нему возможен только в пределах одного класса. Никакой внешний класс не может получить доступ к данным члена этого класса. Если вам нужен доступ к этим переменным, вы должны использовать публичные методы «getter» и «setter».
Методы Getter и Setter используются для создания, изменения, удаления и просмотра значений переменных.
Следующий код является примером методов получения и установки:
В приведенном выше примере метод getBalance() – это метод получения, который считывает значение переменной account_balance, а метод setNumber() – это метод установки, который устанавливает или обновляет значение для переменной account_number.
Абстракция и Инкапсуляция – разница
Часто инкапсуляция неправильно понимается как абстракция. Давай учиться-
Простым примером, чтобы понять эту разницу, является мобильный телефон. Где сложная логика в печатной плате инкапсулирована в сенсорном экране, и интерфейс предоставлен, чтобы абстрагировать ее.
Инкапсуляция в Java
Что такое инкапсуляция
С помощью инкапсуляции мы защищаем данные от неправомерного использования.
Если еще проще
Как применяется инкапсуляция
Есть несколько способов регулировать доступ к нашим данным. Основные это:
Модификаторы доступа
Существуют четыре модификатора доступа:
На самом деле по названиям не сложно понять, что каждый из них означает:
Модификаторы доступа пишутся перед названиями переменных, методов и даже классов:
Инкапсуляция
В чем же преимущества инкапсуляции? Их достаточно много, но я могу выделить четыре, на мой взгляд, основных:
1) Валидное внутреннее состояние.
В программах часто возникают ситуации, когда несколько классов, взаимодействуют с одним и тем же объектом. В результате их совместной работы нарушается целостность данных внутри объекта — объект уже не может продолжить нормально работать.
Поэтому объект должен следить за изменениями своих внутренних данных, а еще лучше – проводить их сам.
Если мы не хотим, чтобы какая-то переменная класса менялась другими классами, мы объявляем ее private, и тогда только методы её же класса смогут получить к ней доступ. Если мы хотим, чтобы значения переменных можно было только читать, но не изменять, тогда нужно добавить public getter для нужных переменных.
Например, мы хотим, чтобы все могли узнать количество элементов в нашей коллекции, но никто не мог его поменять без нашего разрешения. Тогда мы объявляем переменную private int count и метод public getCount().
Правильное использование инкапсуляции гарантирует, что ни один класс не может получить прямой доступ к внутренним данным нашего класса и, следовательно, изменить их без контроля с нашей стороны. Только через вызов методов того же класса, что и изменяемые переменные.
Лучше исходить из того, что другие программисты всегда будут использовать твои классы самым удобным для них образом, а не самым безопасным для тебя (для твоего класса). Отсюда и ошибки, и попытки заранее избавиться от них.
2) Контроль передаваемых аргументов.
Иногда нужно контролировать аргументы, передаваемые в методы нашего класса. Например, наш класс описывает объект «человек» и позволяет задать дату его рождения. Мы должны проверять все передаваемые данные на их соответствие логике программы и логике нашего класса. Например, не допускать 13-й месяц, дату рождения 30 февраля и так далее.
— А зачем кому-то указывать в дате рождения 30 февраля?
— Во-первых – это может быть ошибка ввода данных от пользователя.
Во-вторых, прежде чем программа будет работать как часы, в ней будет много ошибок. Например, возможна такая ситуация.
Программист пишет программу для определения людей, у которых день рождения послезавтра. Например, сегодня 3 марта. Программа добавляет к текущему дню месяца число 2 и ищет всех, кто родился 5 марта. Вроде бы все верно.
Вот только, когда наступит 30 марта программа не найдет никого, т.к. в календаре нет 32 марта. В программе становится гораздо меньше ошибок, когда в методы добавляют проверку переданных данных.
— Помню, когда мы изучали ArrayList, я смотрел его код, и там была проверка индекса в методах get и set: index больше или равен нулю и меньше длины массива. Там еще кидалось исключение, если в массиве нет элемента с таким индексом.
— Да, это классический пример проверки входных данных.
3) Минимизация ошибок при изменении кода классов.
Представим, что мы написали один очень полезный класс, когда участвовали в большом проекте. Он так всем понравился, что другие программисты начали использовать его в сотнях мест в своем коде.
Класс оказался настолько полезен, что ты решил его улучшить. Но если ты удалишь какие-то методы этого класса, то код десятков людей перестанет компилироваться. Им придется срочно все переделывать. И чем больше переделок, тем больше ошибок. Ты поломаешь кучу сборок, и тебя будут ненавидеть.
А когда мы меняем методы, объявленные как private, мы знаем, что нигде нет ни одного класса, который вызывал бы эти методы. Мы можем их переделать, поменять количество параметров и их типы, и зависимый код будет работать дальше. Ну, или как минимум, компилироваться.
4) Задаем способ взаимодействия нашего объекта со сторонними объектами.
Мы можем ограничить некоторые действия, допустимые с нашим объектом. Например, мы хотим, чтобы объект можно было создать только в одном экземпляре. Даже если его создание происходит в нескольких местах проекта одновременно. И мы можем сделать это благодаря инкапсуляции.
Как я заново открыл для себя инкапсуляцию в java.
Я всегда считал, что Java — лаконичный и красивый (в плане концепции) язык с четкой структурой, позволяющей расширять эту структуру и на всевозможные фреймворки, там самым помогающая привнести порядок и в код конечного программиста. И, прежде всего, я считал, что java — это 100% ОО язык! Но недавно мне попался код, после которого я вечер ходил возмущался. Код совершенно несложный для понимания даже людей несведующий в java.
Допустим у нас есть класс А в некотором пакете:
Как видно поле x является защищенным и, согласно доке от sun, это поле не видимо ни в подклассах А, ни в пакете test, ни тем более в других пакетах. Поэтому у нас есть все основания считатать, что метод test() возвращает всегда число 33. Более того, мы бы могли использовать это предположение в своем коде, завязав на этом какую-либо логику.
Далее, имеем класс в любом другом пакете (но в пределах этой же JVM):
Вот и все. Все наши предположения о инкапсуляции и неизменности поля А.х развеяны. Метод А.test() теперь возвращает число 34 (и, если мы завязали на этом какую-нибудь логику, то наш код вряд ли теперь будет работать корректно). И даже может показаться, что нарушена одна из трех заповедей ООП — инкапсуляция. Во всем виновен программист пакет java.lang.reflect. Этот пакет предоставляет возможности для работы с объектами на этапе выполнения программы. Т.к. практически все классы этого объекта работают с динамическими структурами, то он довольно медленно работает и должен использоваться лишь в исключительных случаях. Однако возможность его применения остается и нарушение инкапсуляции налицо.
Впоследствии, покапавшись с этим пакетом, я нашел, что за соблюдение безопасности и доступа отвечает специальный класс SecurityManager и, если его запустить, то все становится на свои места. Если нашему классу А добавить статический инициализатор:
То финт ушам, какой получился в предыдущем примере, уже не пройдет. Т.ч. все в порядке, Java по-прежнему ОО язык 🙂 Единственное, для чего я написал этот пост — предупредить (это не сигнал к действию, просто нужно это тоже иметь в виду) всех явистов:
РАЗРАБОТЧИК, БДИ!
При отсутствии SecurityManager на этапе выполнения в твой класс может залезть кто-угодно и изменить что-угодно!
Инкапсуляция
1. Введение
В чем же преимущества инкапсуляции? Их достаточно много, но я могу выделить четыре, на мой взгляд, основных:
2. Валидное внутреннее состояние
В програмах часто возникают ситуации, когда несколько классов взаимодействуют с одним и тем же объектом. В результате их совместной работы нарушается целостность данных внутри объекта – он уже не может продолжать нормально работать.
Поэтому объект должен следить за изменениями своих внутренних данных, а еще лучше — проводить их сам.
Если мы не хотим, чтобы какая-то переменная класса менялась другими классами, мы объявляем ее private, и тогда только методы её же класса смогут получить к ней доступ. Если мы хотим, чтобы значения переменных можно было только читать, но не изменять, тогда нужно добавить public getter для нужных переменных.
Правильное использование инкапсуляции гарантирует, что ни один класс не может получить прямой доступ к внутренним данным нашего класса и, следовательно, изменить их без контроля с нашей стороны. Только через вызов методов того же класса, что и изменяемые переменные.
Лучше исходить из того, что другие программисты всегда будут использовать ваши классы самым удобным для них образом, а не самым безопасным для вас (для вашего класса). Отсюда и ошибки, и попытки заранее избавиться от них.
3. Контроль передаваемых аргументов
Иногда нужно контролировать аргументы, передаваемые в методы нашего класса. Например, наш класс описывает объект «человек» и позволяет задать дату его рождения. Мы должны проверять все передаваемые данные на их соответствие логике программы и логике нашего класса. Например, не допускать 13-й месяц, дату рождения 30 февраля и так далее.
Зачем же кому-то указывать в дате рождения 30 февраля? Во-первых, это может быть ошибка ввода данных от пользователя. Во-вторых, прежде чем программа будет работать как часы, в ней будет много ошибок. Например, возможна такая ситуация.
Программист пишет программу, которая определяет людей, у которых день рождения послезавтра. Например, сегодня 3 марта. Программа добавляет к текущему дню месяца число 2 и ищет всех, кто родился 5 марта. Вроде бы всё верно.
Вот только когда наступит 30 марта, программа не найдет никого, т.к. в календаре нет 32 марта. В программе становится гораздо меньше ошибок, когда в методы добавляют проверку переданных данных.
Помните, когда мы изучали ArrayList и разбирали его код, и там была проверка индекса в методах get и set : index больше или равен нулю и меньше длины массива. Там еще выбрасывалось исключение, если в массиве нет элемента с таким индексом. Это классический пример проверки входных данных.
4. Минимизация ошибок при изменении кода классов
Представим, что мы написали один очень полезный класс, когда участвовали в большом проекте. Он так всем понравился, что другие программисты начали использовать его в сотнях мест в своем коде.
Класс оказался настолько полезен, что вы решили его улучшить. Но если вы удалите какие-то методы этого класса, код десятков людей перестанет компилироваться. Им придется срочно все переделывать. И чем больше переделок, тем больше ошибок. Вы поломаете кучу сборок, и вас будут ненавидеть.
А когда мы меняем методы, объявленные как private, мы знаем, что нигде нет ни одного класса, который вызывал бы эти методы. Мы можем их переделать, поменять количество параметров и их типы, и зависимый код будет работать дальше. Ну или как минимум компилироваться.
5. Задаем способ взаимодействия нашего объекта со сторонними объектами
Мы можем ограничить некоторые действия, допустимые с нашим объектом. Например, мы хотим, чтобы объект можно было создать только в одном экземпляре. Даже если его создание происходит в нескольких местах проекта одновременно. И мы можем сделать это благодаря инкапсуляции.
