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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

Концепція, покладена в основу продуктів типу the Air 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, задовольнить найбільш спокусленого розробника.

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

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

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

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

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