Формальне визначення терміна "чиста мова ОО"?

Я не можу придумати кращого місця серед рідних побратимів, щоб поставити таке питання. Спочатку я хотів запитати "Чи пітон чиста мова ОО"? але враховуючи неприємності та певний дискомфорт, які люди відчувають, намагаючись визначити термін, я вирішив почати з отримання чіткого визначення самого терміна.

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

Існують такі способи підходу до завдання:

1. Дайте порівняльний аналіз, перерахувавши мови програмування, які можуть демонструвати (або не робити цього) певні властивості, унікальні та достатні для визначення терміна (хоча Smalltalk, Scala, Java тощо) - можливі приклади, але IMO цей спосіб не здається дійсно завершеним ні плідно )
2. Дайте формальне визначення (або близьке до нього, наприклад, більш академічним чи математичним стилем).
3. Дайте філософське визначення, яке б повністю спиралося на семантичний контекст конкретної мови або апріорний досвід програмування (повинен бути певний шанс на успішне пояснення громадою).

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

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

[EDIT]

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

NB

як відповісти :

• це допомагає, якщо ви вказали книгу чи довідник, який підтримує / пояснює ваше розуміння термінології та понять (зазвичай, хороше визначення охоплює або посилається на всі залежні поняття, крім елементарних).
• по можливості вкажіть відступну категорію вашої відповіді / визначення, якщо не зрозуміло інакше (див. вище: 1 - на прикладі мови, 2 - математична логіка, 3 - технічний опис та філософія програмування)
• класифікація є важливою (а також тому, що термін pure-OO включений у термін OO), відповідаючи на спробу змістити елементи парадигми OO з інших добре відомих методологій (і аж ніяк не переплутати / перекривати їх, наприклад, як правило, елементи модульного програмування можуть бути охоплені / втілена у програмуванні OO): спробуйте відрізнити OOP від ​​(включаючи або бути частиною) функціонального програмування, логічного програмування (особливо сильно спеціалізованого), типів даних Abstarct (ADT), модульного, метапрограмування (генерики та час розширення LISP), Контракти (наприклад, Ейфелева), орієнтована на аспекти (AO) (різниця між декларативною та функціональною класифікацією, а також історичними визначеннями структурованої Діккстри є чіткою)

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

Так що так, важко дати саме «добре» визначення, а не лише визначення. Але я з позитивом запитую це через ваш досвід та безпосередню участь, хлопці.

OO, за словами Алана Кей, все стосується передачі повідомлень, і це все. Ви побачите, що такі якості, як поліморфізм та інкапсуляція, насправді випливають із передачі повідомлення.

Зараз ця позиція насправді дуже екстремальна, оскільки це в основному означає, що тільки Smalltalk та мови можуть відповідати.

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

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

Знову ж таки, чистота мови ІМХО - це більше слабкість, ніж сила. ОО - це не срібна куля. Жодної єдиної парадигми немає.

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

Зокрема:

• Кожна сутність, над якою працює ваша програма, - це об'єкт першого класу, тобто немає примітивів, вказівників, масивів тощо.
• Єдине, що ви можете зробити з об’єктом, це викликати (потенційно поліморфний) метод на ньому (== надсилання повідомлення). Жодних інших операцій не існує.
• Всі дані інкапсульовані - тобто немає доступу до публічного поля, ви повинні перейти через методи на об'єкті
• Якщо у вас є функції першого класу, то вони також повинні бути об'єктами - значить, вам потрібно зробити щось на кшталтfunctionObject.call(param1,param2)
• Немає глобальних змінних - якщо ви хочете щось подібне, вам потрібно буде використовувати об'єкт для представлення поточного глобального середовища, наприклад, environment.getValue("myThing")або помістити змінну в об'єкт класу

Зауважте, що це все ще залишає відкритими досить багато варіантів:

• Об'єктні моделі на основі класу проти прототипу
• Як реалізується спадкування (якщо воно взагалі є)
• Незалежно від того, чи є у вас разова або багаторазова розсилка щодо методів
• Незалежно від того, чи є ваші об'єкти введені статично чи динамічно
• Точний синтаксис, який використовується для викликів методів (наприклад, у вас може бути синтаксичний цукор для геттерів / сеттерів тощо)

Дискусія про так звані мови OO завжди була дещо змитою з мозку. Тобто:

"Хтось сказав мені, що мова X - це OO, тому мова X дорівнює OO, то кожна мова, у якої відсутні функції мови X, не може бути OO. І тому, що я пишу свій код мовою X, все, що я роблю, є OO. "

Термін об'єктно-орієнтований дизайн зводиться до трьох речей:

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

1) - це чиста програма програми, її можна досягти будь-якою мовою програмування. Однак деякі мови мають корисні функції, такі як клас / структура та приватні ключові слова.

2) - це головним чином програмне проектування, але не може бути досягнуто повністю без мовної підтримки, оскільки для захисту від випадкового використання вам потрібні такі мовні механізми, як приватні / статичні.

3) в основному дизайн програми. Зазвичай є три різні залежності: "об'єкт X містить об'єкт Y", "об'єкт X є різновидом Y" і "об'єкт X взаємодіє з об'єктом Y". Існує багато мовних особливостей, які допомагають вирішити ці залежності: успадкування / поліморфізм, абстрактні базові класи тощо.

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

Вищезазначені цілі неможливо досягти, використовуючи деяку каламутну зворотну логіку: лише тому, що ви використовуєте ключове слово клас, ваша програма автоматично не отримує модульного дизайну. Тільки тому, що ви використовуєте спадщину, це не означає автоматично, що ваші об'єктні залежності мають сенс. Мова з функціями ОО все одно дозволить такі речі, як class TheWholeBloodyProgram"тварина успадковує Кішку".

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

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

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

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

Зрештою, спочатку ви повинні відповісти на питання «Що таке об’єкт?». Більш вузько налаштовані наполягатимуть на успадкуванні від якогось безглуздого універсального базового класу та без потреби виділяти їх на сміттєзбиральну машину. Але я віддаю перевагу набагато кориснішому визначенню. Мета OOP - мати деякі дані та деякі функції, за допомогою яких можна зателефонувати. Так

• Об'єкт містить деякий стан і пропонує деякі функції в цьому стані.

У цьому випадку навіть intкваліфікується. Зрештою, коли ви пишете код шаблону в C ++, який може приймати або примітиви, або предмети, стає важко стверджувати, що примітиви відрізняються істотним чином. Vector v1, v2; v1 + v2;Замість цього немає нічого змістовного int v1, v2; v1 + v2;(окрім хитрої семантики ініціалізації, треба визнати). Крім того, це дозволяє лямбдам і таким речам бути об'єктами, оскільки вони тримають стан - їх захоплення - і пропонують функцію в цьому стані називати лямбда.

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

Ви можете подумати про це на негативному прикладі. Java не є чистою об'єктно-орієнтованою мовою, оскільки існують також примітивні типи, які не є об'єктами. Це цілі числа, парні, масиви тощо. Чистою мовою об'єкта семантика об'єктів доступна для всього.

Існує також питання про те, яка частина мови закрита для модифікації навіть у межах об'єкта. У Java ви не можете визначити нові підкласи для деяких класів, наприклад, String або Class.

Які мови є чистими? Єдиний кандидат, який спадає на думку, - це невеликі розмови.