Об'єктно-орієнтоване програмування (ООП): поліморфізм

Програмування - це процес розробки рішень «живих», динамічних задач у вигляді жорстких конструкцій коду, даних, функцій і алгоритмів. Процедура формування суворого синтаксису з невизначеною семантики. Реальні завдання - відома велика проблема в сенсі алгоритмізації: щоб досягти потрібного рішення, завдання потрібно помістити в точні синтаксичні конструкції. ООП двічі робив спробу «зламати» цю давню концепцію програмування, але «кайдани» класичного стилю кодування даних і алгоритмів все ще міцні.

Рівень і кваліфікація

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


Об'єктивно і те, що розробник не наполягає, а замовник не вимагає реального вирішення реальних завдань. Обидві сторони звикли обмежуватися доступними інструментами і звичними можливостями. Форми поліморфізму ООП, ідеї інкапсуляції коду і успадкування властивостей (методів) лежать у сфері програмування, але ніяк не у сфері розв'язуваної задачі. Показовий приклад - бібліотека PHPOffice/PHPWord. Для її використання потрібна кваліфікація розробника, потрібно створювати власну систему об'єктів, але поточний рівень замовника (вимоги замовника) - це тривіальна композиція, яку програміст перекриває своєю розробкою (інакше не задовольнити вимоги). Ситуація на кшталт такої: В даному випадку застосування бібліотеки - завдання форматування документів, наприклад, диплом чи дисертацію повинні бути оформлені згідно стандарту. Замовник пред'явив свої вимоги, а програміст пішов своїм шляхом набагато далі.


Виконаний повний розбір документа, його збірка в потрібному форматі, виконана робота з таблицями будь-якого рівня вкладеності, злиття та розділення клітинок, друк в будь-якому напрямку і пр.

Поліморфізм і ООП

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

Популярні визначення поліморфізму

ООП - черговий етап розвитку інформаційних технологій. З цим мало хто сперечається, але його основні аксіоми та положення так різняться в частині семантики, що не заслуговують уваги поза їх сукупності.
Поліморфізм-у програмуванні - це здатність надавати один і той же інтерфейс для різних базових форм (типів даних). Поліморфізм - можливість об'єктів мати різну реалізацію. Поліморфізмом називається здатність функції Класика (від творця С/С++): «один інтерфейс - багато реалізацій». Параметричний поліморфізм означає Поліморфізм - положення теорії типів Абстракція неможлива без інкапсуляції і спадкування, як неможливий поліморфізм без успадкування Можна погодитися, що все це відноситься до одного і того ж: але форма вираження думки, сутність і зміст - не подібні. Але щось спільне все ж є.

Сутність: розробник - замовник

Класична розробка програм передбачає наявність програміста і завдання (клієнт, замовник). Програміст досліджує завдання, формалізує її і робить код, який призводить до виконання. Замовник заперечує все запропоноване або тільки його частину, вказуючи на недоробки, і програміст робить свою роботу знову. Такий кругообіг процесу рішення задачі наводить на думку, що тут явно поєднані дві абсолютно різні сутності: комп'ютер не може сам вирішити завдання; потрібна програма, щоб комп'ютер міг «зрозуміти» і «вирішити задачу. Завдання - сфера компетенції замовника, програма - це алгоритм «адаптації» завдання до можливостей комп'ютера - сфера компетенції програміста. Роль останнього полягає в «адаптації» комп'ютера до вимог завдання, а це зайве! Об'єктно-орієнтоване програмування пропонує абстрагуватися . Є об'єкти - це сфера замовника; є реалізація об'єктів - це сфера програміста. Ніякої «технологічної» зв'язку між замовником і розробником. Ідея кардинальна, не реалізована дотепер, але щось вже стабільно працює.

Вікна, кнопки та інші об'єкти

Історія the Air Art Technology, Object Magazine, Turbo Vision, Graph Vision - це вже історія. Мало хто пам'ятає ці реалізації ООП, вони практично не використовуються і забуті, але віконний інтерфейс Windows знайомий мільйонам користувачів, а об'єкти в середовищах PHP, jаvascript і інших мовах інтернет-технологій застосовуються сотнями тисяч розробників коду, про них знають мільйони відвідувачів веб-ресурсів.
Ймовірно, це єдино правильний шлях, по якому повинно було розвиватися ООП: інкапсуляція, успадкування, поліморфізм для розробника, але не для користувача. Характерно, що саме ця позиція була основною при розробці візуального оформлення (інтерфейсу) програмного забезпечення Windows, прикладних програм типу Turbo Vision і Graph Vision. Концепція, покладена в основу продуктів типу the Air Art Technology і Object Magazine, істотно відрізнялася. Тут абстрактний об'єкт був самим першим предком інформаційної структури, инкапсулировал на абстрактному рівні код обробки інформації. Об'єкти вікон, кнопок, елементів візуального оформлення тут були вторинні. У першому варіанті (Windows & etc.) парадигма ООП: інкапсуляція, успадкування, поліморфізм позначалася на рівні абстрактного предка, а реалізація коду формувалася на рівні кожного конкретного нащадка по гілці спадкування згідно з потрібною структурою і змістом. У другому варіанті (the Air Art Technology і Object Magazine) важливий рівень абстрактного об'єкта. Що буде у конкретного нащадка - не суть, головне, щоб його гілка спадкування задовольняла вимогам всіх батьків вниз до кореневої абстракції.

Об'єкт і система об'єктів: алгоритм

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

Об'єкт і система об'єктів: завдання й рішення

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

Традиційне і об'єктне програмування

Базові постулати ООП: інкапсуляція, успадкування, поліморфізм в тому вигляді, в якому вони стали звичними і затребувані, призводять до помітного поліпшення якості і надійності коду, значно прискорюють роботу програміста і мають масу інших позитивних якостей. Але віз і нині там: класичне програмування не поступається своїх позицій, і багато об'єктно-орієнтовані ідеї реалізовані класичним кодом. Однак ідеї ООП і рекурсія призвели до адекватного впливу на синтаксис класичних операторів синтаксису, на логіку побудови звичайного коду, що не має ніякого відношення до об'єктно-орієнтованого стилю письма і мислення. Списки і черги змінилися, з'явилося поняття першого і останнього елемента масиву, з'явилися цикли «по кожному», а зразкові варіанти іменування, використання і виконання стали ще більш затребуваними, ніж раніше. Власне, сам факт, що змінні втратили своє «чітке» особа (тип змінної може змінюватися в міру потреби, а описувати змінну зовсім немає необхідності) каже, що класика, насправді, давно стала об'єктно-орієнтованої і визнала основні принципи ООП: інкапсуляція, успадкування, поліморфізм як ідеї, що мають істотне значення.

Що в основі: об'єкт або система

Абстракція, як основне концептуальне положення ООП, незалежно від того, де знаходиться зона відповідальності (реалізація) об'єкта - на рівні першого абстрактного об'єкта або на рівні конкретного нащадка, - залишає відкритим питання: з чого починати, з об'єкта або системи? Якщо в основу покласти об'єкт, то він ніколи не стане системою, оскільки система буде знаходитися всередині нього, а сам він стане жорстким чином цілком конкретного початку. Тут з абстракцією виникають проблеми: початковий об'єкт точно фіксує основне в розв'язуваній задачі, тобто він вже не переносимо на іншу задачу. Якщо в основу покласти систему об'єктів, то виходить система систем. Це важко уявити у відношенні до конкретної задачі, і з чого починати розробку - теж складно зрозуміти. За великим рахунком, поліморфізм ООП з його відмінностями в сутності, форми реалізації, кількостях актуальних параметрів у функціях дає подання про систему, яка лежить у початку, як: про варіанти вирішення завдання (наприклад, меню); про початкових умовах (застосування завдання в різних умовах, даних); про режимах роботи (тестування, налаштування, робота). Але це і подібне йому не дає жодних підстав ставити в основу вирішення завдання систему об'єктів. Часто достатньо визначити один єдиний початковий об'єкт.

Історія процесу рішення задачі

Найважливіші принципи ООП: поліморфізм і абстракція - визначають пріоритетом початковий об'єкт як систему об'єктів. У спорі, що повинно бути раніше, курка чи яйце, тут перемога дістається курці. Немає ніяких сумнівів в тому, що все повинно починатися з абстрактного об'єкта, а не з системи об'єктів. Але якщо врахувати фактор часу і прикласти його на рівні кожного об'єкта, починаючи з самого першого абстрактного, то суперечлива думка покласти на початок рішення і об'єкт, і систему є єдино розумною. Якщо класична концепція програмування в ході рішення задачі змінює дані, вміст бази даних, змінює файли тощо, то в концепції ООП поліморфізм, інкапсуляція і фактор часу змінюють зміст, структуру та властивості системи об'єктів розв'язуваної задачі. Програміста в ООП менше всього цікавить поняття файл, база даних, алгоритм - це зокрема, тут програміст мислить об'єктами, але об'єкти існують у часі і змінюються в ході досягнення бажаного. Таким чином, на початку лежить об'єкт як система об'єктів і логіка цієї системи - шкала часу: запуск задачі, формування першого об'єкта, введення або збір даних, формування наступного об'єкта, але ніщо не заважає першому об'єкту приступити до наступного рішення. Кожен рівень об'єктів виступає як самостійна система об'єктів, тобто, це один об'єкт, але в контексті розпочатого процесу та значення часу - це система об'єктів на шкалі часу. Для повноцінної реалізації ООП поліморфізм, спадкування і фактор часу в сукупності забезпечують динаміку першого, тобто об'єкт може не тільки змінюватися з плином часу, але і породжувати об'єкти, не передбачені розробником, породжені виконанням завдання по ходу процесу, проектовані замовником.

Реальний поліморфізм ООП, приклад

Складність завдань, що під силу ООП, не порівнянна з тією, що доступна класичного варіанту написання програм. Звичайно, вирішити будь-яке завдання завжди доступно звичайним чином, але питання, скільки це буде коштувати часу і сил, часто робить результат марним. Не так давно була розроблена бібліотека PHPOffice/PHPWord, але для того щоб використовувати її можливості практично завжди доводиться створювати власну систему об'єктів. Наприклад, простий файл *.docx: являє собою zip-архів безлічі файлів і папок у форматі Office Open XML (OpenXML, OOXML). Кожен файл записаний в тегами XML, причому при додавання, зміни та видалення літер, слів, таблиць, списків та ін. елементів вміст файлів починає являти собою послідовність тегів, які не завжди містять повні елементи, часто один елемент записується безліччю тегів. Якщо уявити цей файл у вигляді послідовності тегів, вийде цікава картинка: Легко помітити, що перший і єдиний абзац документа представлений безліччю тегів. Що стосується таблиці і вбудованих в неї таблиці, то обсяг опису всіх елементів не піддається сприйняттю, але доступний об'єктно-орієнтованого додатком. Насправді, на малюнку зелене - це тестовий висновок тегів, жовте - параметри і тип тега, бежеве - зміст. Створені об'єкти орієнтовані на машинну обробку. Для людини стають доступні лише операції відкриття файлу документа, його форматування і запис. Рішення просте і практичне, а от реалізація орієнтована більше на комп'ютер, ніж на людину, причини об'ємності виконуваного функціоналу і складних взаємозв'язків між об'єктами.

Стан області ООП

Розвиток систем управління сайтами, технологій налаштування і управління серверами, досвід розробки динамічних сайтів зробили об'єктно-орієнтоване програмування доступним кожному. Проблема в тому, як змінити своє мислення і звикнути мислити на рівні об'єктів, а не в контексті послідовно виконуваного коду. Зазвичай перехід від класичного програмування до об'єктно-орієнтованого займає два-три місяці, але витрати окупаються з лишком. Потенціал сучасних мов програмування, в першу чергу PHP і jаvascript, задовольнить найвибагливішого розробника. Сучасне ООП - поліморфізм, спадкування та можливості формування властивостей об'єктів - зручні і практичні, синтаксис мов та допоміжні інструменти забезпечують комфорт в роботі і ефективність коду.

Перспективи об'єктної ідеї

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