Инкапсуляция – это упаковка данных и функций в единый компонент. Инкапсуляция, полиморфизм, наследование: особенности

В конце 80-х годов прошлого века в программировании ничего кардинально нового не произошло. Было много языков, много споров и был Turbo Pascal 5.5, а в комплекте его поставки было несколько странных файлов и несколько не привычных конструкций в синтаксисе.

Вероятно, объектно-ориентированное программирование обязано своим появлением неизвестному художнику, а может быть и нескольким, но особенно большой ценности идея объединения кода и данных в те далекие времена не несла. С термином "инкапсуляция" она была связана слабо и косвенно.

Структуры, функции и процедуры

Уже в первых версиях языков программирования, еще до появления первых баз данных стало совершенно ясно, что данное – это не число и не строка символов, а что-то осмысленное. Пусть это будет переменная "счетчик" в цикле или три строчных переменных "фамилия", "имя", "отчество", но это всегда сразу смысл.

"Счетчик" всегда находится после цикла и работает в нем. А "фамилия", "имя", "отчество" будут объявлены рядышком, и их участие во многих участках кода будет совместным. Где-то они будут использоваться самостоятельно, в общем, у них будет один смысл.

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

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

Причины начала инкапсуляции

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

Каждый компилятор и интерпретатор языка старательно брал все новое в свой синтаксис, предлагал разработчикам варианты реализации семантики.

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

Самый тривиальный пример инкапсуляции, который сохранился с давних пор и актуален по сей день. Три переменных "фамилия", "имя", "отчество", где бы они не находились, всегда требуют к себе функций добавления, изменения, удаления. Более того, эти переменные обеспечивают массу конкретных людей, то есть массу экземпляров:

• Иванов, Иван, Иванович;
• Петрова, Ирина, Васильевна;
• Кукушкина, Полина, Григорьевна;
• ... и абстрактный класс ...
• "фамилия", "имя", "отчество";
• ... и три вечные функции ...
• добавить;
• изменить;
• удалить.

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

Время жизни экземпляра инкапсуляции

Инкапсуляция – это данные и код.

• Слово – encapsulation.
• Латинский вариант – in capsula.

Слово «капсула» именно это и означает. То, что многие языки и разработчики додумали (public, protected, private) – тема отдельная и к смыслу инкапсуляции имеет либо относительное, либо применительное отношение.

По большому счету, экземпляр – это просто вариант (слепок, момент) данных, а те три метода живут вечно. Код как информационный фильтр "обеспечивает" жизнь экземпляров, потому как он един для всех, и, кстати, пока что:

• код "постоянен";
• обозначает самое простое неизменное действие.

Но иной экземпляр может "выкинуть" фокус.

Если пример отнесен к штатному расписанию компании, то особенное значение в наборе экземпляров будет иметь директор и бухгалтер. Остальные могут остаться в обычном "виде". У директора и бухгалтера могут появиться свои собственные коды, то есть свои функции.

Это означает, что жизнь экземпляра не всегда определяется функциональность трех магических слов:

• добавить;
• изменить;
• удалить.

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

Начало ООП

"Надо срочно что-то менять", – подумало некоторое количество разработчиков, и в качестве хорошего примера предложило поработать с объектами на Turbo Pascal 6.0 Professional. Это не идеальное предложение, но очень качественное простое и эффективное.

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

Звучит сложно. Положив, что инкапсуляция данных – это простое объединение данных и кода, все очень упрощается и появляется отличная концепция.

Объект – это данные и код. Экземпляр объекта – это только данные, к которым имеет доступ его код. Экземпляров может быть очень много, но код для них всегда один и не прикрепляется к каждому, но доступен каждому.

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

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

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

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

Жизнь ООП

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

С точки зрения скорости приобретения опыта – это эффективная идея, ведь чего прикладывать ООП к автоматизации бухгалтерского труда, когда его можно приложить к меню на HTML-странице?

Очень все просто: есть элемент меню, есть его варианты. Можно предложить пользователю выбирать варианты меню (вертикальное, горизонтальное, выпадающее), можно дать кнопкам формы (круглая, квадратная, округленная и т. д.).

Мало кого интересует труд и жизнь разработчика. Всем нужна бухгалтерия, производство, обучение, потому что нужно выполнять реальные задачи. Значит нужно увеличивать коллективы, но тогда система объектов будет реализовываться различными специалистами и они могут навредить друг другу.

Во многом это поставило ООП на производственные рельсы. Уже не оставалось сомнений: инкапсуляция, наследование – это хороший путь, но как защитить объекты от постороннего вмешательства, как со стороны, так и по родословной линии? Это не обязательно будет хакер. Случайно нанести вред, изменив данные предка, может другой разработчик.

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

Инкапсуляция – это хорошо, но...

PHPWord – мощный продукт, хорошо сделанный и перспективный. Отличная система объектов, продуманная и работающая.

Ниже начало описания внутреннего объекта этого продукта. Одна простая абстракция ячейки таблицы от вообще пустой абстракции – какого-то контейнера. И это далеко не все описание.

Не надо погружаться в дебри, чтобы понять. Использование здесь многочисленных комментариев не придает ясности, а слова protected, private и public вовсе говорят, прежде всего, о том, что сторонний разработчик, используя эту библиотеку, поменял в нужном месте private на public (см. коммент: "sc 19.06.2016 было привате").

Это факт ошибки в коде, которую при применении разработчик был вынужден исправить, а, следовательно, ему потребовалось что-то изменить.

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

Жизнь в разработке и жизнь в применении. Характерная черта современного программирования – жесткое отрицание преемственности. Если раньше разработчик гарантировал, что каждая новая версия будет дополнять и улучшать предшествующую, то сегодня каждая новая версия объекта, языка, среды программирования кардинально или как минимум принципиально отличается от предыдущей.

Даже условия размещения на хостинге могут измениться так, что придется переделывать код. А часто это очень даже непросто.

Хорошая наследственность, хороший выход

От ошибок никто не застрахован. А всякое новое дело требует знаний. PHPWord – хорошая библиотека, и к ней нужно просто привыкнуть. Много специалистов потратили много времени. Разработчик, собравшийся ее применить, должен уделить достаточно времени изучению структуры вордовского файла. Это не секрет.

Система объектов PHPWord станет прозрачной и доступной. Она дается как есть, но если есть желание идти дальше, потому как текущий функционал недостаточен. Хорошая идея. Тогда это уже другая система объектов, и лучше, если она пойдет дальше.

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

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

Правильная инкапсуляция

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