Сообщение от Dmitry A. Soshnikov
Инкапсуляция
С этой идеей часто возникает путаница и ошибки в восприятии. В данном случае мы будем рассматривать один из удобных “сахаров” некоторых реализаций ООП, — всем известные модификаторы: private, protected и public, которые также называются уровнями (или модификаторами) доступа к характеристикам объектов.
Я хочу выделить и напомнить самый главный момент, касающийся сущности инкапсуляции: инкапсуляция — это усиление абстракции, но никак не параноидальное сокрытие от “злых хакеров”, которые “то и норовят, что-то записать напрямую в поля ваших классов”.
Это самая большая (и распространённая) ошибка — использовать сокрытие ради сокрытия.
Уровни же доступа — private, protected и public — были введены в ряде реализаций ООП исключительно для удобства самого программиста (и действительно, являются достаточно удобным “сахаром” — поэтому и были введены), чтобы более абстрактно представлять и описывать систему.
Наиболее хорошо, это можно видеть в некоторых реализациях (опять же, в тех же Python’e и Ruby). С одной стороны (в Python), это __private и _protected свойства (определяются именованием через ведущие подчёркивания) и не доступны снаружи. С другой стороны, Python просто переименовывает такие поля определённым образом (_ИмяКласса__имя_поля), и под этим именем они уже доступны снаружи.
Или в Ruby: с одной стороны, есть возможность определять private и protected характеристики, с другой стороны, так же есть ряд методов (например, instance_variable_get, instance_variable_set, send и т.д.), позволяющих получить доступ к инкапсулированным данным.
Основная причина: программист сам, сознательно хочет получить доступ к инкапсулированным (обратите внимание, я специально не использую термин “скрытым”) данным. А значит, если они будут как-то неверно изменены или будет какая-то ошибка, то в ответе за это полностью и осознанно программист, а не просто “опечатка” или “кто-то случайно изменил какое-то поле”. Однако в частых подобных случаях, всё-таки, есть смысл говорить о плохом стиле программирования.
Основной же ролью инкапсуляции, повторим, является абстрагирование от пользователя вспомогательных сущностей и никак не “способ обезопасить объект от хакеров”. Для безопасности программного обеспечения применяются куда более серьёзные меры, нежели модификатор “private”.
Инкапсулирия вспомогательные (локальные) объекты, мы обеспечиваем возможность дальнейших изменений поведения public-интерфейса с минимумом затрат, локализуя и прогнозируя места этих изменений. И именно в этом заключается главная суть инкапсуляции.
Так же важной задачей сеттера является абстрагирование сложных вычислений. Например, сеттер element.innerHTML — мы просто абстрактно говорим — “теперь html этого элемента будет таким”, в то время, как внутри функции-сеттера для свойства innerHTML будут сложные вычисления и проверки. Здесь речь идёт об абстракции, но инкапсуляция, как усиление её — имеет место быть.
Само же понятие инкапсуляции может и не быть связано с ООП. Так, например, в качестве инкапсулирующей сущности может выступать и обычная функция, которая инкапсулирует в себе различные вычисления, делая использование её абстрактным (пользователю не важно знать, как реализована, к примеру, функция Math.round(…), он просто её вызывает). Это — есть инкапсуляция реализации и, обратите внимание, ни о каких private, protected, public в этом моменте речи не идёт.
|
