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

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 понял!

Answer 2

[Steel_Balls]

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

Answer 3

[mayton2019]

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

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

Answer 4

[fkk]

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

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

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

Comments

[Василий]

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

[fkk]

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

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