Инкапсуляция действий со ссылками Теперь накоплено достаточно подтверждений того, что любая система моделирования и разработки ПО должна поддерживать понятие ссылки, а, следовательно, и динамические псевдонимы. Как теперь справиться с неприятными последствиями?

24.5.4 Инкапсуляция защищенной полезной нагрузки Заголовок инкапсуляции защищенной полезной нагрузки протокола IP (IP Encapsulating Security Payload) применяется как для режима транспорта, так и для режима туннеля.Формат этого заголовка показан на рис. 24.8. Получатель использует индекс SPI

Инкапсуляция и извлечение данных Стек протоколов хорошо иллюстрирует перемещение данных между программными компонентами, поддерживающими сетевое взаимодействие, однако он не дает ответа на вопрос, какие же изменения претерпевает информация на этом пути. На различных

Инкапсуляция IP При работе в локальной сети на базе технологии CSMA/CD возможны два варианта инкапсуляции датаграмм IP в кадры уровней LLC и MAC.Первый заключается в использовании кадров Ethernet 2.0. В этом случае поле данных (1500 октетов) полностью принадлежит IP-датаграмме, a SAP

Но в действительности обширно встречается и в других (см. подтипизация на записях и полиморфизм записей и вариантов). В ООП инкапсуляция тесно связана с принципом абстракции данных (не путать с абстрактными типами данных , реализации которых предоставляют возможность инкапсуляции, но имеют иную природу). Это, в частности, приводит к другому распространённому заблуждению - рассмотрению инкапсуляции неотрывно от сокрытия . В частности, в сообществе С++ или Java принято рассматривать инкапсуляцию без сокрытия как неполноценную. Однако, некоторые языки (например, Smalltalk , Python) реализуют инкапсуляцию в полной мере, но не предусматривают возможности сокрытия в принципе. Другие (Standard ML , OCaml) жёстко разделяют эти понятия как ортогональные и предоставляют их в семантически различном виде (см. сокрытие в языке модулей ML).

Энциклопедичный YouTube

1 / 3

✪ Что такое геттеры и сеттеры для класса. Методы get и set. Инкапсуляция это. Пример. C++ Урок #76

✪ Python Tutorial - 39 - Classes Encapsulation

✪ OCJA (1Z0 - 808) || Object Oriented Programming: Encapsulation

Субтитры

Подробности

PHP5

class A { private $a ; // скрытое свойство private $b ; // скрытое свойство private function DoSomething () //скрытый метод { //actions } public function ReturnSomething () //открытый интерфейс { //actions } };

В этом примере закрыты свойства $a и $b для класса A с целью предотвращения повреждения этих свойств другим кодом, которому необходимо предоставить только права на чтение.

Хранение объектов в памяти. Доступ к свойствам из методов

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

Для устранения неоднозначности в этом вопросе было введено понятие "экземпляр объекта ". Каждая переменная объектного типа является экземпляром соответствующего типа. Для каждого экземпляра создается свой набор свойств, под которые выделяется память. Свойства одного экземпляра никак не связаны со свойствами другого экземпляра. Это и понятно: если в программе есть объект "зубчатое колесо", и мы должны моделировать зубчатую передачу, то свойства у ведущего и ведомого колес будут разными. А вот методы у всех экземпляров совершенно одинаковы. Их хранят в единственной копии для всех экземпляров объекта данного типа (Рис. 5.2).

Иными словами, все экземпляры объекта пользуются одним набором методов, но разными и не связанными между собой наборами свойств.

Рис. 9.2. Хранение объектов в памяти.

Следующая трудность возникает при доступе к свойству объекта. Рассмотрим пример кода:

TYPE TA=CLASS
a:WORD;
PROCEDURE abc;
…
PROCEDURE TA.abc;
VAR a:BYTE;
BEGIN
a:=10
END;

Чему будет присваиваться значение 10 при выполнении метода abc – локальной переменной с именем а, описанной внутри этого метода, или же свойству объекта с тем же именем а? Если свойству объекта, то каким образом программа будет знать, о каком из экземпляров объекта идет речь? Метод abc – общий на все экземпляры, в каждом из экземпляров есть свойство а. Какое же из них менять?

Для устранения неопределенности используется ключевое слово SELF – указатель на текущий экземпляр объекта:

PROCEDURE TA.abc;
VAR a:BYTE;
BEGIN
Self.a:=10 { присваивание свойству }
a:=20 { присваивание локальной переменной }
END;

Self всегда знает, с каким экземпляром объекта идет работа. Откуда? Это очень просто – с каждым экземпляром объекта связано имя объектной переменной. Это же имя ставится перед вызываемым методом, например, x.abc. Имея такую информацию, компилятор будет знать, что внутри метода слово Self в данный момент заменяет собой имя переменной х.

Создаваемые программистом объекты могут включаться в библиотеки и использоваться не только им лично, но и многими другими разработчиками программ. Следовательно, нужно предусмотреть какую-то защиту от неверного использования свойств и методов. С другой стороны, как мы уже видели, прямое изменение значений свойств объекта – операция крайне нежелательная (изменили модуль зуба, а диаметр пересчитать забыли). Эти два соображения привели к появлению принципа инкапсуляции , гласящего: значения свойств не должны меняться напрямую, а только через вызовы соответствующих методов . Рассмотрим два примера программного кода:

В первом случае значение свойства а можно менять напрямую, просто написав с.а:=10. Это явное нарушение принципа инкапсуляции. Во втором случае для изменения значения свойства а введен специальный метод SetA. Внутри этого метода при необходимости будут пересчитываться значения других свойств, зависящих от значения свойства а. Кроме того, можно выполнять проверку корректности присеваемого свойству значения. Если речь идет о свойстве "число зубьев зубчатого колеса", то это число не может быть меньше шести (что, кстати, отражено в самом слове "шестеренка"), иначе не получится плавного зацепления.

Таким образом, инкапсуляция нужна по следующим соображениям:

1. Изменение значения одного из свойств часто должно приводить к изменению значения другого свойства.

2. Возможна проверка корректности присваиваемых свойству значений.

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

TYPE TA=CLASS
PRIVATE
a:REAL;
PUBLIC
b:REAL
END;

Перед списком скрытых свойств ставится слово PRIVATE, а перед списком открытых для изменения свойств – слово PUBLIC. В приведенном фрагменте свойство а является скрытым и попытка выполнить оператор вида с.а:=10 приведет к ошибке "Field identifier expected". Однако внутри методов все скрытые свойства видны по-прежнему. Рекомендуется делать скрытыми все свойства объекта

ООП с примерами (часть 2)

• Учебный процесс в IT

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

Для этого я постарался на более-менее живых примерах объяснить базовые понятия ООП (класс, объект, интерфейс, абстракция, инкапсуляция, наследование и полиморфизм).

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

Инкапсуляция

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

Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали
реализации от пользователя.

Инкапсуляция неразрывно связана с понятием интерфейса класса. По сути, всё то, что не входит в интерфейс, инкапсулируется в классе.

Абстракция

Абстрагирование – это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

Если бы для моделирования поведения автомобиля приходилось учитывать химический состав краски кузова и удельную теплоёмкость лампочки подсветки номеров, мы никогда бы не узнали, что такое NFS.

Полиморфизм

Всё дело в том, что основные элементы управления автомобиля имеют одну и ту же конструкцию и принцип действия. Водитель точно знает, что для того, чтобы повернуть налево, он должен повернуть руль, независимо от того, есть там гидроусилитель или нет.
Если человеку надо доехать с работы до дома, то он сядет за руль автомобиля и будет выполнять одни и те же действия, независимо от того, какой именно тип автомобиля он использует. По сути, можно сказать, что все автомобили имеют один и тот же интерфейс, а водитель, абстрагируясь от сущности автомобиля, работает именно с этим интерфейсом. Если водителю предстоит ехать по немецкому автобану, он, вероятно выберет быстрый автомобиль с низкой посадкой, а если предстоит возвращаться из отдалённого маральника в Горном Алтае после дождя, скорее всего, будет выбран УАЗ с армейскими мостами. Но, независимо от того, каким образом будет реализовываться движение и внутреннее функционирование машины, интерфейс останется прежним.

Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Например, если вы читаете данные из файла, то, очевидно, в классе, реализующем файловый поток, будет присутствовать метод похожий на следующий: byte readBytes(int n);
Предположим теперь, что вам необходимо считывать те же данные из сокета. В классе, реализующем сокет, также будет присутствовать метод readBytes . Достаточно заменить в вашей системе объект одного класса на объект другого класса, и результат будет достигнут.

При этом логика системы может быть реализована независимо от того, будут ли данные прочитаны из файла или получены по сети. Таким образом, мы абстрагируемся от конкретной специализации получения данных и работаем на уровне интерфейса. Единственное требование при этом – чтобы каждый используемый объект имел метод readBytes .

Наследование

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

Очевидно, что все три модификации будут иметь большинство свойств прежней модели (старый добрый двигатель 1970 года, непробиваемая ходовая часть, зарекомендовавшая себя отличным образом на отечественных дорогах, коробку передач и т.д.). При этом каждая из моделей будет реализовать некоторую новую функциональность или конструктивную особенность. В данном случае, мы имеем дело с наследованием.
Наследование – это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым или родительским. Новый класс – потомком, наследником или производным классом.

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

Действительно, в нашем примере мы могли бы произвести с новыми автомобилями все те же действия, что и со старым: увеличить или уменьшить скорость, повернуть, включить сигнал поворота. Однако, дополнительно у нас бы появилась возможность, например, включить противотуманные фонари.

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

Программа, разработанная с помощью ОО подхода (объектно-ориентированного), представляет собой действующую модель решаемой задачи.

Терминология

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

От общего к частному: ООП » (инкапсуляция, наследование, полиморфизм, [композиция]) » GRASP » GoF

Преимущества, цели и принципы ОО подхода

1. Естественность . Построение модели на функциональном уровне, а не на уровне реализации. Использование объектов из конкретной доменной модели (предметной области).
2. Надежность , сопровождение , расширение . Достигается за счет изолированности компонент системы. Изменение одной компоненты не влияет (не должно влиять) на другие части.
   

Инкапсуляция

Понятие инкапсуляции ООП полностью заимствовало из модульного программирования.

Три характерных признака эффективной инкапсуляции

1. Абстракция - процесс упрощения сложной схемы взаимодействия объектов путём изъятия всех несущественных, оставляя только корневые объекты и супер-важные связи. Преимущества : упрощение решения и повторное использование объектов из разных доменных областей. Важно : грань между абстракцией и детализацией очень тонка.
2. Сокрытие реализации (за интерфейсом) - нужно для защиты объектов от пользователя и наоборот.
3. Делегирование ответственности .

Правила эффективной абстракции

1. Нужно рассматривать общий случай, а не конкретный;
2. Нужно распознать основной принцип, а не только общую последовательность;
3. Абстрагируясь, нужно вспоминать о решаемой задаче;
4. Абстракцию можно применять к задачам, которые уже решались вами не менее 3-х раз;
5. Абстракция не всегда очевидна. А также не возможно написать абстрактную программу на любой случай;

Как эффективно скрывать реализацию и создавать слабосвязанные объекты

1. Доступ к данным абстрактного типа должен осуществляться только через методы интерфейса (скрываем реализацию);
2. Исключить возможность бесконтрольного доступа к структурам данных;
3. Не следует угадывать тип данных, если поведение метода не описано в интерфейсе;
4. Быть осторожным при написании 2-х тесно связанных типов;

Наследование

Наследование используется для простоты расширения класса. При наследовании нужно соблюдать сигнатуру методов (конструкторы тоже, с версии PHP 5.4). При наследовании допускается понижение строгости при указании области видимости (уровня доступа).

Полиморфизм

Полиморфизм ввели для простого и гибкого изменения программ.

Классы, методы, свойства

Типы классов:

• Абстрактный;
• Класс, который содержит по крайней мере один абстрактный метод, должен быть определен как абстрактный;
• Нельзя создать экземпляр абстрактного класса;
• Интерфейс;
• Методы интерфейсов не могут содержать реализацию и должны быть публичными;
• Класс не может реализовать два интерфейса, содержащих одноименную функцию;
• Интерфейсы могут наследоваться;
• Сигнатуры методов в реализующем классе должны точно соответствовать сигнатурам в интерфейсе;

Типы методов:

• Абстрактный;
• Не содержат реализации, а требует ее в дочернем классе;
• Статический;
• Реализация не переопределяется (в отличие от абстрактных);