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

В кінці 80-х років минулого століття в програмуванні нічого кардинально нового не сталося. Було багато мов, багато суперечок і був Turbo Pascal 5.5 а в комплекті постачання було кілька дивних файлів і кілька не звичних конструкцій в синтаксисі. Ймовірно, об'єктно-орієнтоване програмування зобов'язане своєю появою невідомому художнику, а може бути і кільком, але особливо великої цінності ідея об'єднання коду і даних в ті далекі часи не несла. З терміном "інкапсуляція" вона була пов'язана слабо і побічно.

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

Вже в перших версіях мов програмування, ще до появи перших баз даних стало абсолютно ясно, що дане – це не число і не рядок символів, а щось осмислене. Нехай це буде змінна "лічильник" в циклі або три рядкових змінних "прізвище", "ім'я", "по батькові", але це завжди відразу сенс.

"Лічильник" завжди знаходиться після циклу і працює в ньому. А "прізвище", "ім'я", "по батькові" будуть оголошені поряд, і їх участь у багатьох ділянках коду буде спільним. Де вони будуть використовуватися самостійно, загалом, у них буде один сенс. Функції та процедури спочатку з'явилися як загальні шматочки коду. Їх використання спочатку передбачалося в інших місцях програми. Їх поява в програмі обумовлювало повторення блоків одних і тих же дій. Винос повтору у вигляді функції або процедури спрощував місця повторів, зменшував об'єм коду і спрощував налагодження. Це не було об'єктно-орієнтованим програмуванням, але класичний стиль кодування з самого початку своєї еволюції займався узагальненням даних, створенням структур і функціональних ділянок коду.

Причини початку інкапсуляції

Інкапсуляція в програмуванні почалася задовго до появи ООП. Це було в надрах класичного стилю, це не зважало функціональне програмування, структурний і всяке інше, яке прагнуло знайти шлях в майбутнє. Кожен компілятор і інтерпретатор мови старанно брав все нове в свій синтаксис, пропонував розробникам варіанти реалізації семантики. Інформація ніколи не була статичною, просто програмування досі задовольняється її формалізованим варіантом. Але навіть будучи строго формалізованої, інформація забезпечує роботою код, який завжди з нею пов'язаний. Інформація ніколи не може бути статичною.

Самий тривіальний приклад інкапсуляції, який зберігся з давніх пір актуальне донині. Три змінних "прізвище", "ім'я", "по батькові", де б вони не перебували, завжди вимагають до себе функцій додавання, редагування, видалення. Більш того, ці змінні забезпечують масу конкретних людей, тобто масу примірників: Іванов, Іван, Іванович; Петрова, Ірина Василівна; Кукушкіна, Поліна, Григорівна; і абстрактний клас "прізвище", "ім'я", "по батькові"; і три вічні функції додати; змінити; видалити. Таких конструкцій на будь-якому рівні (адреси, робочі посади, штатний розклад, виробничий план) можна придумати безліч. І складність реалізації іншої конструкції буде надзвичайно тривалою.

Час життя примірника інкапсуляції

Інкапсуляція – це дані і код. Слово – encapsulation. Латинський варіант – in capsula. Слово «капсула» саме це і означає. Те, що багато мов і розробники додумали (public, protected, private) – тема окрема і до змісту інкапсуляції має або відносне, або применительное ставлення. За великим рахунком, примірник – це просто варіант (зліпок, момент) даних, а ті три методу живуть вічно. Код як інформаційний фільтр "забезпечує" життя примірників, бо він єдиний для всіх, і, до речі, поки що :
код "постійний"; позначає найпростіше незмінне дію. Але інший примірник може "викинути" фокус". Якщо приклад віднесений до штатного розпису компанії, то особливе значення в наборі примірників матиме директор і бухгалтер. Інші можуть залишитися в звичайному вигляді". У директора і бухгалтера можуть з'явитися свої власні коди, тобто свої функції. Це означає, що життя примірника не завжди визначається функціональність трьох магічних слів: додати; змінити; видалити. Якщо приклад віднесений до першого польоту людини в космос, то добрий десяток кандидатів у перші космонавти буде мати масу особливої функціональності, добра сотня людей (примірників) буде за ними наглядати по-особливому, ще буде багато варіантів фахівців, у яких буде дуже багато особливих функцій.

Початок ООП

"Треба терміново щось міняти", – подумало деяку кількість розробників, і в якості гарного прикладу запропонував попрацювати з об'єктами на Turbo Pascal 6.0 Professional. Це не ідеальне пропозицію, але дуже якісне просте і ефективне.

Поклавши, що "інкапсуляція, поліморфізм, спадкування – це основа об'єкта, отримаємо непоганий початок. Поліморфізм дає необхідну динаміку, тому як екземпляри можуть мати різну функціональність. Це потрібно як-то "узаконити" в об'єкті. Спадкування дає можливість відобразити в об'єкті однорідність, побудувати генеалогічне древо формалізованої інформації. Звучить складно. Поклавши, що інкапсуляція даних – це просте об'єднання даних і коду, все дуже спрощується і з'являється відмінна концепція. Об'єкт – це дані і код. Екземпляр об'єкту – це лише дані, до яких має доступ його код. Примірників може бути дуже багато, але код для них завжди один і не прикріплюється до кожного, але доступний кожному. Коли екземпляр об'єкта вимагає до себе особливої уваги, просто з'являється ще один об'єкт, у якого буде покращена функціональність, то є він успадковує, все що було в вихідному об'єкті, але додає щось своє.
Світ поповнюється примірниками другого об'єкта, у яких теж з'являються нові потреби. Нова функціональність і новий об'єкт. Але не кожен новий об'єкт може мати нащадків. Деяких вони навіть вже не потрібні. В результаті такого будівництва виходить гілляста картина об'єктів, а в реальності вона дає життя масі примірників, пов'язаних між собою родоводами і функціональними сполуками. Ідеальний варіант реалізації завдання в стилі ООП – це коли інкапсуляція, поліморфізм, спадкування продумані настільки якісно, що код в програмі геть відсутній . Об'єкти самі по собі виконують свої функції, користуються тільки своїм кодом, вибудовують відносини між собою.

Життя ООП

В реальності все виглядає зовсім інакше. Інкапсуляція – це добре і тут не посперечаєшся. Але правильно побудувати картину об'єктів, продумати функціональність кожного, передбачити, як поведуть себе ті чи інші екземпляри, що можна очікувати від даних, непросто. Довелося спростити ситуацію, і ООП пішла по стежці автоматизації праці розробника, а не вирішення реальних завдань. З точки зору швидкості набуття досвіду – це ефективна ідея, адже чого прикладати ООП до автоматизації бухгалтерського праці, коли його можна додати до меню на HTML-сторінці? Дуже все просто: є елемент меню, є його варіанти. Можна запропонувати користувачеві вибирати варіанти меню (вертикальне, горизонтальне, випадаюче), можна дати кнопок форми (кругла, квадратна, округлена тощо). Мало кого цікавить праця і життя розробника. Всім потрібна бухгалтерія, виробництво, навчання, бо треба виконувати реальні завдання. Значить потрібно збільшувати колективи, але тоді система об'єктів буде реалізовуватися різними фахівцями і вони можуть нашкодити один одному. Багато в чому це поставило ООП на виробничі рейки. Вже не залишалося сумнівів: інкапсуляція, спадкування – це хороший шлях, але як захистити об'єкти від стороннього втручання, як зі сторони, так і по лінії родоводу? Це не обов'язково буде хакер. Випадково нанести шкоду, змінивши дані предка, може інший розробник. Сучасне програмування – це багато розробників, які перебувають у безлічі віддалених офісів. Як бджілки, сучасні розробники будують одну загальну структуру об'єктів. Кожен об'єкт повинен бути побудований за загальними правилами, а ті дані і методи, за які відповідає один програміст, не повинні бути доступні іншим. Коли комусь щось потрібно – це інша тема. За базовим принципом, кожен робить свою справу на своєму ділянці.

Інкапсуляція – це добре, але

PHPWord – потужний продукт, добре зроблений і перспективний. Відмінна система об'єктів, продумана та дієва. Нижче початок опису внутрішнього об'єкта цього продукту. Одна проста абстракція клітинки таблиці від взагалі порожній абстракції – якогось контейнера. І це далеко не весь опис. Не треба занурюватися в нетрі, щоб зрозуміти. Використання тут численних коментарів не додає ясності, а слова protected, private і public зовсім говорять, насамперед, про те, що сторонній розробник, використовуючи цю бібліотеку, поміняв в потрібному місці private на public (див. комент: "sc 19062016 було приваті"). Це факт помилки в коді, яку при застосуванні розробник був змушений виправити, а, отже, йому треба було щось змінити. Можна припустити, що на етапі розробки потрібно обмежити доступ до тих чи інших об'єктів, але тут вже важливо зовсім інше. Є життя примірників, є життя об'єктів, але вже є нове життя – те, що відбувається з системою об'єктів в її застосуванні. Життя в розробці і життя в застосуванні. Характерна риса сучасного програмування – жорстке заперечення спадкоємності. Якщо раніше розробник гарантував, що кожна нова версія буде доповнювати і покращувати попередню, то сьогодні кожна нова версія об'єкта, мови, середовища програмування кардинально або як мінімум принципово відрізняється від попередньої. Навіть умови розміщення на хостингу можуть змінитися так, що доведеться переробляти код. А часто це дуже навіть непросто.

Хороша спадковість, хороший вихід

Від помилок ніхто не застрахований. А будь-яке нове справа вимагає знань. PHPWord – хороша бібліотека, й до неї треба просто звикнути. Багато фахівців витратили багато часу. Розробник, який зібрався її застосувати, повинен приділити достатньо часу вивченню структури вордівского файлу. Це не секрет. Система об'єктів PHPWord стане прозорою та доступною. Вона дається як є, але якщо є бажання йти далі, тому як поточний функціонал недостатній. Хороша ідея. Тоді це вже інша система об'єктів, і краще, якщо вона піде далі. Не так вже й погана ідея жорсткого заперечення спадкоємності: вона стимулює розвиток знань. Об'єкти, побудовані одним колективом розробників, – це їхні міркування про те, як вирішувати задачу, як представити її функціонал. Розуміння цього рішення іншою компанією розробників – це трансформація досвіду. Якщо уявити собі, що це тільки прообраз потрібної системи об'єктів, то чому просто не успадкувати його? Хороша спадковість – риса природнього інтелекту, розраховувати на щось адекватне з боку програмування – це з області майбутнього, хоча і найближчого.

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

Інкапсуляція – це зовсім не комбінація даних і коду. Це поєднання доступного з бажаним. Якщо мислити не даними і алгоритмами, а сприймати дійсність і здійснювати адекватну інкапсуляцію, успадкування це дія від розробника до постачальника, то імовірно: поява систем об'єктів, що переміщаються і саморазвивающихся, все ж можливо.