инкапсуляция определение прав доступа
Инкапсуляция определяется как процесс включения одного или нескольких элементов в физический или логический пакет. Инкапсуляция в методологии объектно-ориентированного программирования препятствует доступу к деталям реализации.
Спецификатор общего доступа
Открытый спецификатор доступа позволяет классу подвергать свои переменные-члены и функции-члены другим функциям и объектам. Доступ к любому публичному члену можно получить извне класса.
Следующий пример иллюстрирует это:
Когда приведенный выше код компилируется и выполняется, он производит следующий результат:
Функция участника Display () и GetArea () также может напрямую обращаться к этим переменным без использования какого-либо экземпляра класса.
Спецификатор частного доступа
Спецификатор частного доступа позволяет классу скрыть свои переменные-члены и функции-члены от других функций и объектов. Только функции одного класса могут обращаться к своим частным членам. Даже экземпляр класса не может получить доступ к своим частным членам.
Следующий пример иллюстрирует это:
Когда приведенный выше код компилируется и выполняется, он производит следующий результат:
Защищенный спецификатор доступа
Защищенный спецификатор доступа позволяет дочернему классу обращаться к переменным-членам и функциям-членам его базового класса. Таким образом, это помогает в реализации наследования. Мы обсудим это более подробно в главе наследования.
Внутренний спецификатор доступа
Спецификатор внутреннего доступа позволяет классу подвергать свои переменные-члены и функции-члены другим функциям и объектам в текущей сборке. Другими словами, любой член с внутренним спецификатором доступа может быть доступен из любого класса или метода, определенных в приложении, в котором определяется член.
Следующая программа иллюстрирует это:
Когда приведенный выше код компилируется и выполняется, он производит следующий результат:
В предыдущем примере обратите внимание, что функция-член GetArea ()не объявлена с помощью любого спецификатора доступа. Тогда какой будет спецификатор доступа по умолчанию для члена класса, если мы не будем упоминать о нем?
Защищенный спецификатор внутреннего доступа
Защищенный спецификатор внутреннего доступа позволяет классу скрыть свои переменные-члены и функции-члены из других объектов и функций класса, кроме дочернего класса в одном приложении. Это также используется при реализации наследования.
Инкапсуляция в Си++ и Си
Определение
Инкапсуляция это набор инструментов для управления доступом к данным или методам которые управляют этими данными. С детальным определением термина “инкапсуляция” можно ознакомиться в моей предыдущей публикации на Хабре по этой ссылке. Эта статья сфокусирована на примерах инкапсуляции в Си++ и Си.
Инкапсуляция в Си++
По умолчанию, в классе ( class ) данные и методы приватные ( private ); они могут быть прочитаны и изменены только классом к которому принадлежат. Уровень доступа может быть изменен при помощи соответствующих ключевых слов которые предоставляет Си++.
В Си++ доступно несколько спецификаторов, и они изменяют доступ к данным следующим образом:
Для краткости, только два уровня (приватный и публичный) будут освещены в примерах.
Пример инкапсуляции
Попытка напечатать или изменить приватную переменную mobile_number из основной программы ( main ) вызовет ошибку при компиляции потому как доступ к приватным данным в классе ограничен.
Нарушение инкапсуляции с Друзьями (Хорошая практика)
В Си++ присутствует ключевое слово “друг” ( friend ) которое позволяет добавить исключения в общие правила доступа к данным. Если функция или класс названы другом ( friend ) класса Contact — они получают свободный доступ к защищенным или приватным данным.
Существует два основных правила дружбы — дружба не наследуется и не взаимна. Также, наличие “друзей” не изменяет уровень защищенности данных — приватные данные остаются приватными с исключением в виде “друга”.
Примечание: друзьями лучше не злоупотреблять. Добавление друга стоит рассматривать как исключение, не как общую практику.
Нарушение инкапсуляции с Преобразованием типов и Указателями (Плохая практика)
Прежде всего, стоит заметить что использовать указатели и преобразование типов таким способом — плохая идея. Этот способ не гарантирует получения нужных данных. Он плохо читается и плохо поддерживается. Невзирая на это, он существует.
Си++ получил в наследство от Си множество инструментов, один из которых — преобразование типов ( typecasting ). По умолчанию, все переменные и методы в классе приватные. В то же время, стандартный уровень доступа к данным в структуре ( struct ) — публичный. Возможно создать структуру или полностью публичный класс в котором данные будут расположены идентично данным в классе Contact и используя преобразование типов получить доступ к приватным данным.
Приватные данные были прочитаны и изменены благодаря преобразованию типов
Инкапсуляция в Си
Традиционно считается что инкапсуляция — один из ключевых ООП принципов. Тем не менее, это не лимитирует использование этого принципа в процедурно-ориентированных языках. В Си, инкапсуляция используется давно, невзирая на отсутствие ключевых слов “приватный” и “публичный”.
Приватные переменные
В данном примере, структура была определена в отдельном исходном файле “private_var.c”. Поскольку инициализация структуры в Си требует выделения и освобождения памяти, несколько вспомогательных функций были добавлены.
В соответствующем заголовочном файле «private_var.h», структура Contact была объявлена, но ее содержание осталось скрытым для основной программы.
Таким образом, для “main.c” содержание структуры неизвестно и попытки прочитать или изменить приватные данные вызовут ошибку при компиляции.
Получение доступа к приватным переменным с Указателями
Преобразование типов может быть использовано для преодоления инкапсуляции в Си также как и в Си++, но данный подход уже был описан. Зная, что в структуре данные расположены в порядке их декларации, указатели и арифметика указателей подойдет для достижения цели.
Доступ к переменным в структуре ограничен. Тем не менее, спрятаны только переменные, не память в которой хранятся данные. Указатели можно рассматривать как ссылку на адрес памяти, и если эта память доступна программе — данные сохраненные в этой памяти можно прочитать и изменить. Если указатель назначен на память в которой структура хранит свои данные — их можно прочитать. Используя то же определение структуры (те же “.c” и “.h” файлы) и модифицированный “main.c” файл, ограничение доступа было преодолено.
Данные в структуре были прочитаны и модифицированы
Приватные функции
Функции, будучи внешними ( extern ) по умолчанию, видимы во всей так называемой единице трансляции ( translation unit ). Другими словами, если несколько файлов скомпилированы вместе в один объектный файл, любой из этих файлов сможет получить доступ к любой функции из любого другого файла. Использование ключевого слова “статический” ( static ) при создании функции ограничит ее видимость до файла в котором она была определена.Следовательно, для обеспечения приватности функции необходимо выполнить несколько шагов:
В соответствующем заголовочном файле «private_funct.h», print_numbers() была декларирована как статическая функция.
Получение доступа к приватным функциям
Вызвать функцию print_numbers() из основной программы возможно. Для этого можно использовать ключевое слово goto или передавать в main указатель на приватную функцию. Оба способа требуют изменений либо в исходном файле “private_funct.c”, либо непосредственно в теле самой функции. Поскольку эти методы не обходят инкапсуляцию а отменяют её, они выходят за рамки этой статьи.
Заключение
Инкапсуляция существует за пределами ООП языков. Современные ООП языки делают использование инкапсуляции удобным и естественным. Существует множество способов обойти инкапсуляцию и избежание сомнительных практик поможет ее сохранить как в Си, так и в Си++.
ООП с примерами (часть 2)
Волею судьбы мне приходится читать спецкурс по паттернам проектирования в вузе. Спецкурс обязательный, поэтому, студенты попадают ко мне самые разные. Конечно, есть среди них и практикующие программисты. Но, к сожалению, большинство испытывают затруднения даже с пониманием основных терминов ООП.
Для этого я постарался на более-менее живых примерах объяснить базовые понятия ООП (класс, объект, интерфейс, абстракция, инкапсуляция, наследование и полиморфизм).
Первая часть посвящена классам, объектам и интерфейсам.
Вторая часть, представленная ниже, иллюстрирует инкапсуляцию, полиморфизм и наследование
Инкапсуляция
Представим на минутку, что мы оказались в конце позапрошлого века, когда Генри Форд ещё не придумал конвейер, а первые попытки создать автомобиль сталкивались с критикой властей по поводу того, что эти коптящие монстры загрязняют воздух и пугают лошадей. Представим, что для управления первым паровым автомобилем необходимо было знать, как устроен паровой котёл, постоянно подбрасывать уголь, следить за температурой, уровнем воды. При этом для поворота колёс использовать два рычага, каждый из которых поворачивает одно колесо в отдельности. Думаю, можно согласиться с тем, что вождение автомобиля того времени было весьма неудобным и трудным занятием.
Теперь вернёмся в сегодняшний день к современным чудесам автопрома с коробкой-автоматом. На самом деле, по сути, ничего не изменилось. Бензонасос всё так же поставляет бензин в двигатель, дифференциалы обеспечивают поворот колёс на различающиеся углы, коленвал превращает поступательное движение поршня во вращательное движение колёс. Прогресс в другом. Сейчас все эти действия скрыты от пользователя и позволяют ему крутить руль и нажимать на педаль газа, не задумываясь, что в это время происходит с инжектором, дроссельной заслонкой и распредвалом. Именно сокрытие внутренних процессов, происходящих в автомобиле, позволяет эффективно его использовать даже тем, кто не является профессионалом-автомехаником с двадцатилетним стажем. Это сокрытие в ООП носит название инкапсуляции.
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали
реализации от пользователя.
Инкапсуляция неразрывно связана с понятием интерфейса класса. По сути, всё то, что не входит в интерфейс, инкапсулируется в классе.
Абстракция
Представьте, что водитель едет в автомобиле по оживлённому участку движения. Понятно, что в этот момент он не будет задумываться о химическом составе краски автомобиля, особенностях взаимодействия шестерён в коробке передач или влияния формы кузова на скорость (разве что, автомобиль стоит в глухой пробке и водителю абсолютно нечем заняться). Однако, руль, педали, указатель поворота (ну и, возможно, пепельницу) он будет использовать регулярно.
Абстрагирование – это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.
Если бы для моделирования поведения автомобиля приходилось учитывать химический состав краски кузова и удельную теплоёмкость лампочки подсветки номеров, мы никогда бы не узнали, что такое NFS.
Полиморфизм
Любое обучение вождению не имело бы смысла, если бы человек, научившийся водить, скажем, ВАЗ 2106 не мог потом водить ВАЗ 2110 или BMW X3. С другой стороны, трудно представить человека, который смог бы нормально управлять автомобилем, в котором педаль газа находится левее педали тормоза, а вместо руля – джойстик.
Всё дело в том, что основные элементы управления автомобиля имеют одну и ту же конструкцию и принцип действия. Водитель точно знает, что для того, чтобы повернуть налево, он должен повернуть руль, независимо от того, есть там гидроусилитель или нет.
Если человеку надо доехать с работы до дома, то он сядет за руль автомобиля и будет выполнять одни и те же действия, независимо от того, какой именно тип автомобиля он использует. По сути, можно сказать, что все автомобили имеют один и тот же интерфейс, а водитель, абстрагируясь от сущности автомобиля, работает именно с этим интерфейсом. Если водителю предстоит ехать по немецкому автобану, он, вероятно выберет быстрый автомобиль с низкой посадкой, а если предстоит возвращаться из отдалённого маральника в Горном Алтае после дождя, скорее всего, будет выбран УАЗ с армейскими мостами. Но, независимо от того, каким образом будет реализовываться движение и внутреннее функционирование машины, интерфейс останется прежним.
Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
Например, если вы читаете данные из файла, то, очевидно, в классе, реализующем файловый поток, будет присутствовать метод похожий на следующий: byte[] readBytes( int n );
Предположим теперь, что вам необходимо считывать те же данные из сокета. В классе, реализующем сокет, также будет присутствовать метод readBytes. Достаточно заменить в вашей системе объект одного класса на объект другого класса, и результат будет достигнут.
При этом логика системы может быть реализована независимо от того, будут ли данные прочитаны из файла или получены по сети. Таким образом, мы абстрагируемся от конкретной специализации получения данных и работаем на уровне интерфейса. Единственное требование при этом – чтобы каждый используемый объект имел метод readBytes.
Наследование
Представим себя, на минуту, инженерами автомобильного завода. Нашей задачей является разработка современного автомобиля. У нас уже есть предыдущая модель, которая отлично зарекомендовала себя в течение многолетнего использования. Всё бы хорошо, но времена и технологии меняются, а наш современный завод должен стремиться повышать удобство и комфорт выпускаемой продукции и соответствовать современным стандартам.
Нам необходимо выпустить целый модельный ряд автомобилей: седан, универсал и малолитражный хэтч-бэк. Очевидно, что мы не собираемся проектировать новый автомобиль с нуля, а, взяв за основу предыдущее поколение, внесём ряд конструктивных изменений. Например, добавим гидроусилитель руля и уменьшим зазоры между крыльями и крышкой капота, поставим противотуманные фонари. Кроме того, в каждой модели будет изменена форма кузова.
Очевидно, что все три модификации будут иметь большинство свойств прежней модели (старый добрый двигатель 1970 года, непробиваемая ходовая часть, зарекомендовавшая себя отличным образом на отечественных дорогах, коробку передач и т.д.). При этом каждая из моделей будет реализовать некоторую новую функциональность или конструктивную особенность. В данном случае, мы имеем дело с наследованием.
Наследование – это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым или родительским. Новый класс – потомком, наследником или производным классом.
Необходимо отметить, что производный класс полностью удовлетворяет спецификации родительского, однако может иметь дополнительную функциональность. С точки зрения интерфейсов, каждый производный класс полностью реализует интерфейс родительского класса. Обратное не верно.
Действительно, в нашем примере мы могли бы произвести с новыми автомобилями все те же действия, что и со старым: увеличить или уменьшить скорость, повернуть, включить сигнал поворота. Однако, дополнительно у нас бы появилась возможность, например, включить противотуманные фонари.
Отсутствие обратной совместимости означает, что мы не должны ожидать от старой модели корректной реакции на такие действия, как включения противотуманок (которых просто нет в данной модели).
Инкапсуляция в Python 3
Определение
Значение термина «инкапсуляция» расплывчато и отличается от источника к источнику. Принято считать, что инкапсуляция — один из основополагающих принципов ООП, хотя некоторые научные статьи вовсе упускают инкапсуляцию из списка. К примеру, Джон Митчелл в книге «Концепты в языках программирования» при перечислении основных концептов в ООП упоминает только абстракцию — термин который принято считать близким к инкапсуляции по значению, но все-же более обширным и высокоуровневым. С другой стороны, Роберт Мартин в его книге «Чистая архитектура» явно говорит о том, что инкапсуляция, наследование и полиморфизм считается фундаментом ООП.
Разнообразие определений, данных термину «инкапсуляция», сложно привести к общему знаменателю. В целом можно выделить два подхода к значению этого термина. Инкапсуляция может быть рассмотрена как:
Инкапсуляция как связь
Подобного рода трактовка термина «инкапсуляция» очень проста в объяснении. В данном случае, любой класс в котором есть хотя бы одна переменная и один метод который ею управляет наглядно демонстрирует этот принцип.
Класс “Phone” объединяет данные в переменной “number” с методом “print_number()”
Можно создать класс, который состоит только из методов (и не содержит переменных), что может быть удобно в некоторых языках программирования. Также возможно создать класс содержащий только данные, без методов, чего, во многих случаях, следует избегать. Обе практики следует применять в случае необходимости и их отношение к «объединяющей» инкапсуляции спорно.
Инкапсуляция как управление доступом
Объяснение концепции ограничения доступа к данным или методам требует гораздо большего количества деталей. Прежде всего, в этом контексте термин «доступ» следует понимать как способность видеть и / или изменять внутреннее содержимое класса. Существует несколько уровней доступа, предоставляемых большинством ООП языков. Обобщая можно сказать что данные объекта могут быть:
Большинство языков имеют дополнительные степени доступа, которые находятся между этими границами. К примеру, в C++ и Python3 есть три уровня доступа: публичный, защищенный и приватный; C# добавляет ключевое слово «внутренний» ( internal ) в список.
Стоит отметить, что в большинстве языков программирования, уровень доступа к любым данным установлен по умолчанию. Например, в C++ по умолчанию уровень доступа к данным в классе задан как приватный— к его данным могут обращаться только члены и друзья класса. Стандартный уровень доступа к структуре ( struct ) в C++ отличается — он публичный, и данные в такой структуре могут быть доступны любому. Уровень доступа для переменных и методов класса в Python 3 полностью зависит от синтаксиса.
Примеры
Инкапсуляция
Python 3 предоставляет 3 уровня доступа к данным:
Для краткости и простоты, только два базовых уровня (приватный и публичный) освещены в примере.
Доступ к публичным переменным и методам можно получить из основной программы. Попытка получить приватные данные или запустить приватный метод приведет к ошибке.
Нарушение инкапсуляции
Сам язык предоставляет программисту синтаксический инструмент, который может обойти инкапсуляцию. Читать и изменять частные переменные и вызывать частные функции все же возможно.
Несколько слов о Магии
Существуют методы, так называемые «магические методы» («magic methods») или «специальные методы» («special methods»), которые позволяют классам определять свое поведение в отношении стандартных языковых операторов. Примером таких языковых операторов могут служить следующие выражения:
Python 3 поддерживает множество таких методов, полный список можно найти на странице официальной документации языка. __init__ (инициализатор) является наиболее часто используемым из них и запускается при создании нового объекта класса. Другой, __lt__ (расширенное сравнение), определяет правила для сравнения двух объектов пользовательского класса. Такие методы не попадают в категорию «приватных» или «публичных», поскольку служат другим целям и корнями глубоко уходят во внутреннюю структуру языка.
Магические методы могут быть вызваны любым пользователем таким же образом как и любой публичный метод в Питоне, однако они предназначены для неявного использования в своих особых случаях. Специальный случай для метода __init__ — инициализация нового объекта класса. __lt__ служит для сравнения двух объектов.
Заключение
Python3 не обеспечивает ограниченный доступ к каким-либо переменным или методам класса. Данные, которые должны быть скрыты, на самом деле могут быть прочитаны и изменены. В Python3 инкапсуляция является скорее условностью, и программист должен самостоятельно заботиться о ее сохранении.
12.4 – Функции доступа и инкапсуляция
Зачем делать переменные-члены закрытыми?
В предыдущем уроке мы упоминали, что переменные-члены класса обычно делаются закрытыми. Разработчикам, изучающим объектно-ориентированное программирование, часто бывает трудно понять, зачем это нужно. Чтобы ответить на этот вопрос, давайте начнем с аналогии.
В современной жизни у нас есть доступ ко многим электронным устройствам. У вашего телевизора есть пульт дистанционного управления, который можно использовать для включения/выключения телевизора. Вы едете на работу на машине (или скутере). Вы делаете фотографию на свой смартфон. Все эти три вещи используют общий шаблон: они предоставляют простой интерфейс (кнопка, руль и т.д.), который вы можете использовать для выполнения действия. Однако то, как на самом деле работают эти устройства, от вас скрыто. Когда вы нажимаете кнопку на пульте дистанционного управления, вам не нужно знать, что он делает для связи с телевизором. Когда вы нажимаете педаль газа в автомобиле, вам не нужно знать, как двигатель внутреннего сгорания заставляет колеса вращаться. Когда вы делаете фотографию, вам не нужно знать, как датчики собирают свет в пиксельное изображение. Такое разделение интерфейса и реализации чрезвычайно полезно, поскольку позволяет нам использовать объекты, не понимая, как они работают. Это значительно упрощает использование этих объектов и увеличивает количество объектов, с которыми мы можем взаимодействовать.
По тем же причинам разделение реализации и интерфейса полезно и в программировании.
Инкапсуляция
В объектно-ориентированном программировании инкапсуляция (также называемая сокрытием информации) – это процесс скрытия деталей о том, как реализован объект, от пользователей этого объекта. Вместо этого пользователи получают доступ к объекту через открытый, общедоступный интерфейс. Таким образом, пользователи могут использовать объект, не понимая, как он реализован.
В C++ мы реализуем инкапсуляцию через спецификаторы доступа. Как правило, все переменные-члены класса делаются закрытыми (скрывая детали реализации), а большинство функций-членов делаются открытыми (открывая интерфейс для пользователя). Хотя требование, чтобы пользователи класса использовали открытый интерфейс, может показаться более обременительным, чем предоставление открытого доступа к переменным-членам напрямую, это на самом деле дает большое количество полезных преимуществ, которые помогают стимулировать повторное использование класса и его поддерживаемость.
Примечание. Слово инкапсуляция также иногда используется для обозначения упаковки данных и функций, которые работают с этими данными. Мы предпочитаем называть это объектно-ориентированным программированием.
Преимущество: инкапсулированные классы проще в использовании и уменьшают сложность ваших программ
Преимущество: инкапсулированные классы помогают защитить ваши данные и предотвратить неправильное использование
Глобальные переменные опасны тем, что у вас нет строгого контроля над тем, кто имеет доступ к этим глобальным переменным, или как они используются. Классы с открытыми членами страдают от той же проблемы, только в меньшем масштабе.
Например, предположим, что мы пишем строковый класс. Мы могли бы начать так:
Эти две переменные имеют внутреннюю связь: m_length всегда должна быть равна длине строки, содержащейся в m_string (это соединение называется инвариантом). Если бы m_length была открытой, любой мог бы изменить длину строки, не изменяя m_string (или наоборот). Это поставило бы класс в несогласованное состояние, что могло бы вызвать всевозможные странные проблемы. Делая m_length и m_string закрытыми, пользователи вынуждены для работы с этим классом использовать любые доступные открытые функции-члены (а эти функции-члены могут гарантировать, что m_length и m_string всегда устанавливаются правильно).
Мы также можем помочь защитить пользователя от ошибок при использовании нашего класса. Рассмотрим класс с открытой переменной-членом массива:
Если пользователи могут получить доступ к массиву напрямую, они могут попытаться использовать его с недопустимым индексом, что приведет к неопределенным результатам:
Однако если мы сделаем массив закрытым, то сможем заставить пользователя использовать функцию, которая сначала проверяет, что индекс корректен:
Таким образом, мы защитили целостность нашей программы. Кстати, функции at() классов std::array и std::vector делают нечто очень похожее!
Преимущество: инкапсулированные классы легче изменять
Рассмотрим простой пример:
Инкапсуляция дает нам возможность изменить способ реализации классов, не нарушая работу всех программ, которые их используют.
Вот инкапсулированная версия этого класса, который использует функции для доступа к m_value1 :
Теперь давайте изменим реализацию класса:
Обратите внимание: поскольку мы не изменяли прототипы каких-либо функций в открытом интерфейсе нашего класса, наша программа, использующая данный класс, продолжает работать без каких-либо изменений.
Точно так же, если бы гномы пробрались ночью в ваш дом и заменили внутренности вашего пульта от телевизора на другую (но совместимую) технологию, вы, вероятно, даже не заметили бы этого!
Преимущество: инкапсулированные классы легче отлаживать
И, наконец, инкапсуляция помогает вам отлаживать программу, когда что-то идет не так. Часто, когда программа работает некорректно, это происходит потому, что одна из наших переменных-членов имеет неправильное значение. Если получить доступ к переменной напрямую могут все, то отследить, какой фрагмент кода изменил эту переменную, может быть трудно (это может быть любой, и вам нужно будет установить точки останова везде, чтобы выяснить, где же ее изменили). Однако если для изменения значения все должны вызывать одну и ту же открытую функцию, вы можете просто установить точку останова на этой функции и наблюдать, как каждый вызывающий меняет значение, пока не увидите, где что-то пошло не так.
Функции доступа
В зависимости от класса нам может быть целесообразно (в контексте того, что делает класс) иметь возможность напрямую получать или устанавливать значение закрытой переменной-члена.
Функция доступа – это короткая открытая функция, задачей которой является получение или изменение значения закрытой переменной-члена. Например, в классе MyString вы можете увидеть что-то вроде этого:
Функции доступа обычно бывают двух видов: геттеры и сеттеры. Геттеры (англ. «getter», также иногда называемые аксессорами) – это функции, возвращающие значение закрытой переменной-члена. Сеттеры (англ. «setter», также иногда называемые мутаторами) – это функции, которые устанавливают значение закрытой переменной-члена.
Вот пример класса, у которого есть геттеры и сеттеры для всех его членов:
Приведенный выше класс Date – это, по сути, инкапсулированная структура данных с тривиальной реализацией, и пользователь этого класса может разумно ожидать, что сможет получить или установить значение дня, месяца или года.
Приведенный выше класс MyString используется не только для передачи данных – он имеет более сложную функциональность и инвариант, который необходимо поддерживать. Для переменной m_length не было предусмотрено никакого сеттера, потому что мы не хотим, чтобы пользователь мог устанавливать длину напрямую (длина должна устанавливаться только при изменении строки). В этом классе имеет смысл разрешить пользователю напрямую получать длину строки, поэтому был предоставлен метод-геттер длины.
Геттеры должны предоставлять доступ к данным «только для чтения». Поэтому лучше всего возвращать их по значению или по константной ссылке (а не по неконстантной ссылке). Геттер, который возвращает неконстантную ссылку, позволит вызывающему изменить реальный объект, на который та ссылается, что нарушает суть геттера «только для чтения» (и нарушает инкапсуляцию).
Лучшая практика
Геттеры должны возвращать результат по значению или константной ссылке.
Проблемы с функциями доступа
Существует немало дискуссий о том, в каких случаях следует использовать функции доступа или избегать их. Хотя они не нарушают инкапсуляцию, некоторые разработчики утверждают, что использование функций доступа нарушает хороший дизайн классов ООП (тема, которая может легко заполнить всю книгу).
А пока мы рекомендуем прагматичный подход. При создании классов учитывайте следующее:
Резюме
Как видите, инкапсуляция при небольших дополнительных затратах усилий дает множество преимуществ. Основное преимущество заключается в том, что инкапсуляция позволяет нам использовать класс, не зная, как он был реализован. Это значительно упрощает использование незнакомых нам классов.