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

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

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

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

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

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

Форми поліморфізму ООП, ідеї інкапсуляції коду і успадкування властивостей (методів) лежать в сфері програмування, але ніяк не в сфері розв'язуваної задачі.

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

В даному випадку застосування бібліотеки - завданняформатування документів, наприклад, диплом або дисертація повинні бути оформлені за стандартом. Замовник пред'явив свої вимоги, а програміст пішов своїм шляхом набагато далі.

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

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

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

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

• інкапсуляція;
• поліморфізм;
• успадкування.

Деякі додають ще: абстракція, і найчастіше саме цей, причому дійсно основний момент, використовують як фундамент для опису сутності ООП.

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

Демократичне початок не властиво областіінформаційних технологій, але слід віддати належне: поєднання і спільне існування безлічі думок про одне й те ж - це реальний поліморфізм в дії.

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

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

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

Можна погодитися, що все це відноситься до одного і того ж: а форма вираження думки, сутність і зміст - не подібні. Але щось спільне все ж є.

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

Класична розробка програм передбачаєнаявність програміста і завдання (клієнт, замовник). Програміст досліджує завдання, формалізує її і робить код, який призводить до вирішення. Замовник заперечує все запропоноване або тільки його частина, вказуючи на недоробки, і програміст робить свою роботу знову.

Такий кругообіг процесу рішення задачі наводить на думку, що тут явно суміщені дві абсолютно різні сутності:

• комп'ютер не може сам вирішити задачу;
• потрібна програма, щоб комп'ютер міг «зрозуміти» і «вирішити» завдання.

Завдання - сфера компетенції замовника, програма -це алгоритм «адаптації» завдання до можливостей комп'ютера - сфера компетенції програміста. Роль останнього полягає в «адаптації» комп'ютера до вимог завдання, а це зайве!

Об'єктно-орієнтоване програмування пропонує абстрагуватися. Є об'єкти - це сфера замовника; єреалізація об'єктів - це сфера програміста. Ніякої «технологічної» зв'язку між замовником і розробником. Ідея кардинальна, що не реалізована донині, але щось вже стабільно працює.

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

Історія the Air Art Technology, Object Magazine,Turbo Vision, Graph Vision - це вже історія. Мало хто пам'ятає ці реалізації ООП, вони практично не використовуються і забуті, але віконний інтерфейс Windows знаком мільйонам користувачів, а об'єкти в середовищах PHP, JavaScript та інших мовах інтернет-технологій застосовуються сотнями тисяч розробників коду, про них знають мільйони відвідувачів веб-ресурсів.

Ймовірно, це єдино правильний шлях, поякому повинно було розвиватися ООП: інкапсуляція, успадкування, поліморфізм для розробника, але не для користувача. Характерно, що саме ця позиція була основною при розробці візуального оформлення (інтерфейсу) програмного забезпечення Windows, прикладних програм типу Turbo Vision і Graph Vision.

Концепція, покладена в основу продуктів типу theAir Art Technology і Object Magazine, істотно відрізнялася. Тут абстрактний об'єкт був найпершим предком інформаційної структури, Інкапсульована на абстрактному рівні код обробки інформації. Об'єкти вікон, кнопок, елементів візуального оформлення тут були вторинні.

У першому варіанті (Windows & etc.) Парадигма ООП: інкапсуляція, успадкування, поліморфізм позначалася на рівні абстрактного предка, а реалізація коду формувалася на рівні кожного конкретного нащадка по гілці успадкування згідно потрібним структурою і змістом.

У другому варіанті (the Air Art Technology іObject Magazine) важливий рівень абстрактного об'єкта. Що буде у конкретного нащадка - не суть, головне, щоб його гілка успадкування задовольняла вимогам всіх батьків вниз до кореневої абстракції.

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

Ідеальна об'єктно-орієнтована концепція може маніпулювати тільки об'єктами і системами об'єктів.

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

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

Це ідеально для простого ООП:поліморфізм дає можливість робити, зокрема, різноманітні елементи дизайну, але керувати ними одним і тим же кодом. Але тут не йдеться про об'єкти завдання, яка зовсім не розглядається як предмет для об'єктно-орієнтованого аналізу.

Програмісти взяли ООП як засіб дляпідвищення якості та продуктивності своєї роботи, але не поступилися ні краплі «своєї території» замовнику. Основні поняття ООП - інкапсуляція, успадкування, поліморфізм - залишилися в сфері розробки, а не трансплантували в сферу завдання.

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

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

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

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

Ідеально, коли робота замовника по створеннюпотрібної йому системи об'єктів і робота по реалізації методів і властивостей цих об'єктів рознесені в часі. Чим далі відстоїть реалізація системи об'єктів (програміст) від її смислового наповнення (замовник), тим якісніше процес.

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

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

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

Але віз і нині там: класичне програмування не поступається своїми позиціями, і багато об'єктно-орієнтовані ідеї реалізовані класичним кодом.

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

Списки і черги змінилися, з'явилося поняттяпершого і останнього елемента масиву, з'явилися цикли «по кожному», а посилальні варіанти іменування, використання і виконання стали ще більш затребуваними, ніж раніше.

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

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

Абстракція, як основне концептуальне положенняООП, незалежно від того, де знаходиться зона відповідальності (реалізація) об'єкта - на рівні першого абстрактного об'єкта або на рівні конкретного нащадка, - залишає відкритим питання: з чого все починати, з об'єкта або з системи?

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

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

• про варіанти вирішення завдання (наприклад, меню);
• про початкових умовах (застосування завдання в різних умовах, даних);
• про режими роботи (тестування, налаштування, робота).

Але це і подібне йому не дає ніяких підстав ставити в основу рішення задачі систему об'єктів. Часто досить визначити один єдиний початковий об'єкт.

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

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

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

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

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

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

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

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

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

Не так давно була розроблена бібліотекаPHPOffice / PHPWord, але для того щоб використовувати її можливості, практично завжди доводиться створювати власну систему об'єктів. Наприклад, простий файл * .docx:

являє собою zip-архів безлічі файлів іпапок в форматі Office Open XML (OpenXML, OOXML). Кожен файл записаний в тегами XML, причому при додаванні, зміну і видалення букв, слів, таблиць, списків тощо. Елементів вміст файлів починає являти собою послідовність тегів, які не завжди містять повні елементи, часто один елемент записується безліччю тегів.

Якщо уявити цей файл у вигляді послідовності тегів, вийде цікава картинка:

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

Насправді, на малюнку зелене - це тестовийвисновок тегів, жовте - параметри і тип тега, бежеве - зміст. Створені об'єкти орієнтовані на машинну обробку. Для людини стають доступні тільки операції відкриття файлу документа, його форматування і запис.

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

Стан галузі ООП

Розвиток систем управління сайтами, технологійнастройки і управління серверами, досвід розробки динамічних сайтів зробили об'єктно-орієнтоване програмування доступним кожному. Проблема в тому, як змінити своє мислення і звикнути мислити на рівні об'єктів, а не в контексті послідовно виконуваного коду.

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

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

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

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

Інструментарій ООП - поліморфізм, успадкування, інкапсуляція і абстракція - орієнтуються на розробника.

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