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

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

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

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

Още в първите версии на езиците за програмиране, още преди появата на първите бази данни, стана абсолютно ясно, че това не е число или низ от символи, а нещо смислено. Нека да бъде променлива "брояч" в линия или три малки променливи "фамилно име", "първо име", "средно име", но винаги има смисъл веднага.

"Броячът" е винаги след цикъла и работи в него. "Фамилно име", "първо име", "средно име" ще бъдат обявени рамо до рамо и тяхното участие в много части на кода ще бъде съвместно. Някъде те ще се използват самостоятелно, като цяло ще имат едно значение.

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

Това не беше обектно-ориентирано програмиране, но от самото начало на своята еволюция класическият стил на кодиране се занимаваше с компилирането на данни, създаването на структури и функционалните секции на кода.

Причините за започване на капсулиране

Инкапсулирането в програмирането започна много преди появата на ООП. Беше в дълбините на класическия стил, означаваше функционален програмиране, структурно и всеки друг, който се стреми да намери начин в бъдещето.

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

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

Най-тривиалният пример за капсулиране, който е запазен дълго време и е актуален и до днес. Три променливи "фамилно име", "първо име", "средно име", където и да са, винаги изискват функциите на добавяне, модификация, изтриване. Освен това, тези променливи осигуряват маса от конкретни хора, т.е. много случаи:

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

Има голямо разнообразие от такива конструкции на всяко ниво (адреси, позиции, персонал, производствен план). И сложността на изпълнението на различен дизайн ще бъде изключително дълго.

Срок на приложение на капсулата

Капсулирането е данни и код.

• Думата е капсулиране.
• Латинска версия - в капсула.

Думата "капсула" е това, което означава. Фактът, че много езици и разработчици са го мислили (публичен, защитен, личен), е отделна тема и има относително или приложено отношение към смисъла на капсулирането.

Като цяло инстанцията е само опция (отпечатък, момент) на данни и тези три метода живеят вечно. Кодът като информационен филтър "гарантира" живота на инстанциите, защото той е един за всички и между другото за сега :

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

Но друг пример може да "изхвърли" фокуса.

Ако примерът е включен в списъка на служителите на дружеството, то директорът и счетоводителят ще имат специално значение в комплекта от копия. Останалата част може да остане в обичайната форма. Директорът и счетоводителят могат да имат свои собствени кодове, т.е. техните собствени функции.

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

• добавете;
• се промени;
• за премахване.

Ако примерът е свързан с първия пилотиран полет в космоса, то тогава дузина кандидати за първите космонавти ще имат много специална функционалност, стотина души (екземпляри) ще ги наблюдават по специален начин, ще има още много възможности за специалисти, които ще имат много специални. функции.

Стартирайте ООП

„Трябва спешно да променим нещо“, помислиха редица разработчици и като добър пример предложиха работа с обекти на Turbo Pascal 6.0 Professional. Това не е идеална оферта, а много високо качество просто и ефективно.

Ако приемем, че "капсулирането, полиморфизмът, наследяването" е в основата на обекта, получаваме добро начало. Полиморфизмът дава необходимата динамика, защото инстанциите могат да имат различна функционалност. Тя трябва по някакъв начин да бъде "легитимирана" в обекта. Наследството дава възможност да се отрази хомогенност в обекта, да се изгради родословно дърво на формализираната информация.

Звучи трудно. Ако приемем, че капсулирането на данни е проста комбинация от данни и код, всичко става много просто и се появява чудесна концепция.

Обектът е данни и код. Екземпляр на обект е само данни, до които кодът му има достъп. Може да има много случаи, но кодът за тях винаги е един и същ и не е свързан с всички, но е достъпен за всички.

Когато случай на обект изисква специално внимание към себе си, просто се появява друг обект, който ще има подобрена функционалност, т.е. наследява всичко, което е в оригиналния обект, но добавя нещо свое.

Светът се попълва с примери на втория обект, който също има нови нужди. Нова функционалност и ново съоръжение.

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

Идеалният вариант на изпълнение на задачите в стила на ООП е, когато капсулирането, полиморфизмът, наследяването се обмислят толкова качествено, че кодът напълно отсъства в програмата. Самите обекти изпълняват своите функции, използват само техния код, изграждат взаимоотношения помежду си.

Живот на ООП

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

От гледна точка на скоростта на натрупване на опит, това е ефективна идея, в края на краищата, защо трябва да се прилага ООП за автоматизацията на счетоводната работа, когато тя може да бъде прикрепена към менюто на HTML страницата?

Всичко е много просто: има елемент от менюто, има опции. Можете да поканите потребителя да избере опции на менюто (вертикално, хоризонтално, падащо), можете да дадете на бутоните формата (кръгла, квадратна, закръглена и т.н.).

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

В много отношения това поставя PLO на производствените релси. Вече нямаше никакво съмнение: капсулирането, наследяването е добър начин, но как да се предпазят обектите от външна намеса, както отвън, така и по линията на родословието? Не е задължително да е хакер. Случайно причиняват щети чрез промяна на данните на предшественика, друг разработчик може.

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

Капсулирането е добро, но ...

PHPWord е мощен продукт, добре направен и обещаващ. Отлична система от обекти, измислена и работеща.

По-долу е началото на описанието на вътрешния обект на този продукт. Една проста абстракция на клетка от таблица от общо празна абстракция - някакъв вид контейнер. И това не е всичко описание.

Няма нужда да се гмуркате в дивата природа, за да разберете. Използването на многобройни коментари тук не дава яснота, а думите защитени, частни и обществени казват, преди всичко, че разработчикът на трета страна, използващ тази библиотека, е променил частния на публичен на правилното място (виж коментара: "sc 06/19/2016 Private ").

Това е факт на грешка в кода, който, когато се прилага, разработчикът е бил принуден да коригира и следователно трябва да промени нещо.

Може да се предположи, че на етапа на разработване е било необходимо да се ограничи достъпът до тези или други обекти, но тук е важно друго. Има живот на инстанции, има живот на обекти, но вече има нов живот - какво се случва със системата от обекти в неговото приложение.

Живот в развитието и живота в приложението. Характерна черта на съвременното програмиране е твърдото отричане на приемствеността. Ако по-рано разработчикът гарантира, че всяка нова версия ще допълни и подобри предишната, то днес всяка нова версия на обекта, езика, програмната среда е фундаментално или поне фундаментално различна от предишната.

Дори условията за хостинг на хостинг услугите могат да се променят, така че трябва да повторите кода. И често е много трудно.

Добра наследственост, добра доходност

Никой не е имунизиран от грешки. И всеки нов бизнес изисква знания. PHPWord е добра библиотека и просто трябва да свикнеш с него. Много професионалисти прекарваха много време. Разработчик, който се е събрал да го използва, трябва да отделя достатъчно време, за да проучи структурата на Word файла. Това не е тайна.

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

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

Разбирането на това решение от друга компания за разработчици е трансформация на опита. Ако си представим, че това е само прототип на необходимата система от обекти, тогава защо просто не го наследим? Добрата наследственост - черта на естествената интелигентност, разчита на нещо адекватно от страна на програмирането - това е от областта на бъдещето, макар и най-близката.

Правилно капсулиране

Инкапсулирането не е комбинация от данни и код. Това е комбинация от наличното и желаното. Ако не мислите с данни и алгоритми, а възприемате реалността и изпълнявате адекватно капсулиране, наследявайки това действие от разработчика на разработчика, то тогава е вероятно: появата на системи от движещи се и самостоятелно развиващи се обекти все още е възможно.