Обьясните в чём суть инкапсуляции?

Question

[Khetag_d]

Я не могу понять в чём суть инкапсуляции?
Тоесть мы создаём переменную с доступом private которым можно манипулировать внутри класса где он создан , и создаём метод внутри этого же класса (геттер и сеттер) и потом в мэйне через метод манипулируем private переменными .
Но как это защищает ?
Тоесть это тупо создаёт что то вроде тонеля через который можно обратиться к переменным , но тем не менее к ним можно обратиться и манипулировать ими , и как это обеспечивает безопасность? Хакер так же по сути может просто обратиться к методу и вертеть всем как хочет, не?

Comments

[Ипатьев]

Мне кажется, вы называете инкапсуляцией что-то не то

[Dmitry Roo]

Геттеры и сеттеры нарушают принцип инкапсуляции, являются антипатерном и примером карго-культа.

[Андрей]

Если как описано - приватная переменная и публичный метод с простым геттером и сеттером, то большой разницы нет.
Но метод может не просто менять переменную. Он может проверять вводимые значения, он может содержать какую-то дополнительную логику, логгирование, проверку прав доступа и что-нибудь еще. Обычно в учебных проектах всё это притянуто за уши и пока не начнешь писать настоящие рабочие проекты, не поймешь.

[Андрей]

Dmitry Roo, ничего они не нарушают, и никаким антипаттерном не являются. Откуда вы это придумываете?

[Василий Банников]

Андрей, Steel_Balls, ну на счёт карго культа вполне справедливо. Очень многие новички слышут, что нужно поля сделать приватными ради инкапсуляции, но в этот же момент добавляют пустой геттер/сеттер, по сути ничего не меняя.

[Андрей]

Василий Банников, ну с этим соглашусь)

[Василий]

у классов есть внутренние состояния. Например класс который загружает файл с диска и сжимает его например, может хранить хендлер на файл. И очень было бы странно давать всем возможность его изменять.

[Dmitry Roo]

Steel_Balls, вроде про solid не было разговора. Только про инкапсуляцию.

[Dmitry Roo]

Андрей, Steel_Balls, предлагаю ознакомиться:
https://www.yegor256.com/2014/09/16/getters-and-se...

[Андрей]

Dmitry Roo, давайте возьмем код джуниора, где разные подходы использованы не к месту, объявим эти подходы плохими, назовем антипаттернами и напишем целую статью. А если заняться совсем нечем, то и целую книгу.
Вот примерно так выглядит эта статья (а может быть и вся книга, на которую ссылается автор).
P.s. общепринятый синтаксис Java всегда казался мне странным, в частности эти самые геттеры и сеттеры, и автор тоже это заметил

That’s why, it is conceptually incorrect to have any methods starting with set or get in an object.

[Dmitry Roo]

Андрей, проблема то как раз в том, что грейды растут, а подходы не изменяются.
Поэтому и существуют книги вроде чистый код, элегантные объекты и т.д...

Answer 1

[Василий Банников]

Инкапсуляция защищает не от хакеров, а от неправильного использования объектов.
Как пример - у тебя может быть класс "Заказ" и у него может быть какой-то статус (оплачен/ждёт оплаты/отменён итд).
При этом у тебя могут быть правила типа: уже оплаченный заказ не может стать вдруг неоплаченным, а отменённый заказ нельзя взять обратно в работу.
Тогда логично будет сделать поле статуса приватным (не доступным для изменения извне напрямую), а менять его только через методы, где будет происходить вся валидация.
(В некоторых языках такие правила принято описывать на уровне типов, чтобы даже валидаций никаких было делать не нужно)

Приватные поля объекта - это его состояние.
Методы объекта - это способы его использования.

Если у тебя в объекте появляется поле x и методы getX / setX (или авто геттеры/сеттеры в C#), то значит, что у тебя и нет явных причин делать это поле приватным, кроме соблюдения общепринятых соглашений.

Comments

[historydev]

Инкапсуляция защищает не от хакеров

ахахывахваых)

[Василий Банников]

historydev, прямой ответ на фразу из вопроса

Хакер так же по сути может просто обратиться к методу и вертеть всем как хочет, не?

[historydev]

Василий Банников, Так я не с ответа смеюсь)

[pavlik 322]

То есть просто убирает возможность менять переменные без проверки?

[Сергей Горностаев]

pavlik 322, то есть просто снижает вероятность ошибки, когда в кодовой базе миллионы строк и сопровождают её десятки программистов в течении десятков лет.

[pavlik 322]

Сергей Горностаев, Я считаю, что идеи запрещать что-либо на уровне языка бессмысленны. Они приводят к сомнительным и спорным запретам на полиморфизм, прямое изменение переменных и даже goto, вынуждая использовать try/catch, нагружать одинаковыми функциями классы и прописывать сеттеры. Программисты разумные люди и стараются всё-таки не допускать алмазов смерти, перехода в строки до инициализации, но при этом сейчас приходится придумывать антипаттерны, которые могут даже работать медленнее

[Сергей Горностаев]

pavlik 322, тогда вам стоит писать на ассемблере, там никаких запретов вообще. Программисты всё же люди и склонны ошибаться, поэтому computer science и существует со всеми этими теориями типов, формальными доказательствами, парадигмами и прочим.

[Василий Банников]

pavlik 322,

Программисты разумные люди

Вам про therac 25 напомнить или сами найдёте?

которые могут даже работать медленнее

Практика показывает, что оверхед от геттеров/сеттеров в частности и от инкапсуляции в общем, очень незначительный. Те же геттеры и сеттеры успешно инлайнятся компилятором.

вынуждая использовать try/catch

Кто и где тебя вынуждает использовать try-catch?

спорным запретам на полиморфизм, прямое изменение переменных и даже goto

Можно перечислить спорные запреты?
goto в C# есть.

[pavlik 322]

Василий Банников, Полиморфизма в C# нет, в therac 25 ошибки были не из-за полиморфизма, goto или доступа к переменным, там явно была просто плохо написана ОС(деление на ноль, переполнение 8-битной переменной). Ну, если goto нет и ты не в php, то без try/catch из сотни вложенных циклов не выйдешь

[pavlik 322]

historydev, Ну он видно из-за Hacker News, по аналогии))

[Василий Банников]

pavlik 322,

там явно была просто плохо написана ОС(деление на ноль, переполнение 8-битной переменной)

Написано там всё было на ассемблере - как раз язык, где можно что угодно ;)
Если ещё почитать, то можно почитать и про "трюкачество" в коде.
Я предположу, что если бы код был написан "тупо", то тогда бы все проблемы были бы очевидны на ревью.
Опять же одна из ошибок была из-за того что в ассемблере нет типов (а в частности boolean).

Полиморфизма в C# нет

Ой. https://learn.microsoft.com/ru-ru/dotnet/csharp/fu...

goto нет

Ой. https://learn.microsoft.com/ru-ru/dotnet/csharp/la...

из сотни вложенных циклов не выйдешь

Есть много способов как можно переписать код так, чтобы у тебя не было сотни вложенных циклов и без try-catch.

[pavlik 322]

Василий Банников, я ошибся и под полиморфизмом подразумевал другое понятие - множественное наследование.
Сергей Горностаев, про computer science понял!

[Василий Банников]

pavlik 322,

множественное наследование

Увы, но это порождало очень много неочевидных ошибок в C++, потому его и нет.
Но:
1. Множество интерфейсов наследовать/реализовывать можно
2. Сейчас вместо наследования принято использовать композицию - это работает гораздо гибче и легче читается.
3. В интерфейсах тоже можно писать код, а не только сигнатуры

[pavlik 322]

Василий Банников, Расскажите, пожалуйста, проблемы, а то вот даже на SO не получилось найти причины отказа: https://stackoverflow.com/questions/406081/why-sho...

[Василий Банников]

pavlik 322, так вот там же же самый залайканный ответ: https://stackoverflow.com/a/407928.

С точки зрения разработчиков языка - проще и надёжнее без множественного наследования реализовать язык и рантайм.

С точки зрения конечного пользователя - меньше думать.

Ну серьёзно, дай хотя бы один реальный пример, где множественное наследование классов (не интерфейсов) логичнее, удобнее, понятнее, чем композиция.

Answer 2

[Steel_Balls]

Суть инкапсуляции - защита внутренних данных класса от изменения извне.
Допустим, ты нарушил этот принцип и сделал поля класса доступными для изменения из любой точки кода напрямую.
Отсюда возникают очевидные проблемы с невозможностью контролировать все эти процессы - кто откуда когда и зачем пытается изменить данные внутри класса.
При реализованной инкапсуляции у нас такой проблемы нет - все данные внутри класса под полным контролем.
При чём здесь вообще хакеры?
ООП, ШП, методологии разработки - это всё создано для разработчиков ПО, а не для хакеров.

Answer 3

[Дмитрий]

Оу, май, 4 человека ответили, и ни один не понимает, что такое инкапсуляция... деградация какая-то, алё!

Причём тут защита данных? Причём тут контроль доступа? Сокрытие данных? Геттеры, сеттеры? private, public?
Это всё не имеет никакого отношения к инкапсуляции, это всё побочные эффекты, либо способы реализации в конкретном языке.

Основная задача инкапсуляции -- отделить интерфейс от реализации. Чтобы пользователя интерфейса вообще не волновало как там устроена его реализация. Чтобы там всё под капотом само подтягивалось, разрешалось, загружалось, а пользователь только передавал входные данные в интерфейс и получал выходные. Чтобы для добавления новой реализации в случае чего, разработчику достаточно было drop-in'ом закинуть эту реализацию, и она сама подтянулась, а не перелопачивать всю кодовую базу, которая сломалась от банального добавления кода.

ООП и его фишки тут не причём. Ни геттеры, ни сеттеры, ни private\public никакого отношения к этому не имеют. Инкапсуляция может быть даже статической, когда, например разрешаются модули во время компиляции, и язык вообще не должен быть объктно-ориентированным при этом. Инкапсуляция может реализовываться вообще распределённо по разным нодам, которые реализуют интерфейс. Да и ещё чёрт знает как. Скрывать данные не нужно от пользователя. Часто даже удобно обратное -- не писать кучу бойлерплейта, а просто дать возможность пользователю сконфигурировать интерфейс через изменение стейтов в его реализации напрямую, если позволяет платформа, соблюдая инварианты. Это будет более верным архитектурным дизайном, нежели городить какие-то костыли "вдруг пользователь идиот и всё поломает".

На этом всё, это и есть инкапсуляция.

Answer 4

[mayton2019]

Инкапсуляция не имеет никакого отношения к хакерам.

Это просто свойство объекта иметь оболочку, которая защищает объект от неправильных изменений.
Неправильные изменения это например корректировка одного поля, которое на самом деле
функционально связанно со всеми другими полями. Например строка и контрольная сумма к строке.
Или время и часовой пояс времени. Или иммутабельность объекта.

Answer 5

[fkk]

В основном это защита от самого себя и своих коллег-обезъян. В первую очередь это контроль доступа, предотвращение кривого изменения состояния объекта и наконец возможность изменять внутреннюю реализацию без изменения внешнего интерфейса.

Например, чтобы какой-то Вася напрямую где-то не расчитал баланс юзера в минус при покупке чего либо, т.к. у тебя в сеттере/методе покупке есть валидация на это дело и тебе ее не нужно везде копипастить, и если например так же валидация поменяется, ты ее поменяшь в одном месте, а не будешь бегать по проекту все места менять. Ну и тестировать такой код проще, меньше шансов где-то накосячить.

Это не про защиту от хакеров.

Comments

[Василий]

Вы говорите о полиморфизме, инкапсуляция это про сокрытие а не повторное использование.

[fkk]

Василий, ну ведь одно из другого вытекает?) Ты сокрыл логику в сеттере, написал там важные бизнес валидации и прочее, и потом переиспользуешь, зная, что никак, кроме как через сеттер никто и нигде тебе не мутирует свойство объекта.

В случае отсутствия сеттера, их придется в нужных местах повторять.

[Василий]

Не правильно, делать валидацию в сеттере, валидация это слой бизнес логики приведу
простой пример есть пользователь у него есть поле возраст при регистрации мы валидируем его что бы н момент регистрации пользователь был старше 18 лет.
А например админ когда создает пользователей мы это пропускаем. Если мы воткнем валидацию в сеттер то нам придется объяснять объекту в каком сценарии он сейчас находится. Это протекание абстракции когда объект знает лишнее.