чи OOP є домінуючою моделлю програмування в реальному світі?

Об'єкти ніколи? Ну, навряд чи колись

У розділі VIEWPOINT Комунікації ACM я знайшов цікаву статтю під назвою " Об'єкти ніколи? Ну, навряд чи колись ". Це кардинально інша перспектива, ніж об'єкти - спочатку або об'єкти - пізно. Він пропонує «об’єкти-ніколи» чи, можливо, «предмети-аспірантура».

Автор розповів про OOP і поставив питання про те, як OOP використовується в реальних умовах програмування. Він вважає, що OOP не є домінуючою моделлю програмування. Наприклад, він стверджує, що 70% програмувань робиться для вбудованих систем, де OOP не дуже підходить.

Коли деякі викладачі в університетах хочуть поговорити про переваги ООП, вони говорять про повторне використання коду. Ще один приклад, знову ж таки, він стверджує, що це не справжній випадок у реальному світі. повторне використання коду важче, ніж заявлено в університетах:

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

Мені цікаво знати, як люди з переповненням стеків думають про це? Чи є OOP домінуючою моделлю програмування з точки зору програмістів?

Якщо я повинен вибрати / вивчити / використовувати лише один підхід, це OOP чи ні? чому?

У розділі VIEWPOINT Комунікації АСМ

Якщо ви зацікавлені в практичному програмуванні , огляд ACM та подібних програм - це останнє джерело, яке ви хочете прочитати. Це часто [псевдо] -наукові публікації, які не застосовуються в реальному світі. Це досить часто неортодоксальні думки, зроблені для публічності, для письменника, щоб відмежувати себе від натовпу та просувати свою власну особу.

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

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

Однак ООП - це не срібна куля. Він працює для деяких розробок, не працює для інших. Як і будь-який інший підхід.

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

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

Якщо OOP - єдина парадигма, яку ви знаєте, можливо, ви повинні дізнатися більше. Але насправді, що насправді означає OOP? Чи означає це Java чи C ++? Це означає Smalltalk? Чи означає це встановлені значення слотів та закриттів? (Привіт, схема!) Чи означає це надсилання повідомлень? (Привіт, Ерланг!)

Коротше кажучи, здається нецікавим питання. "Чи корисний ОО ?" краще питання. І, ну, здається, саме так. (Звичайно, це для мене.)

Де всі розробники роблять ті "70% програмувань"? З усіх розробників, яких я знаю, менше 1% працюють над вбудованими системами.

Отже, у нас є 3 варіанти:

1. Я унікальна, і всі ваші друзі дійсно вбудовують програмування
2. Є армія забудовників, замкнених у підвалі, десь роблять ці 70%
3. ця статистика складається, а стаття - фігня

якщо я не бачу якихось доказів того, що варіанти 1 або 2 насправді є правдою, я йду з варіантом 3.

(BTW, я не вважаю сучасне вбудоване програмування для мобільних пристроїв, і мобільний розвиток часто є OO, адже Apple змушує вас використовувати * Objective * C для розробки для iPhone)

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

Дуже багато додатків просто виконують імперативне програмування, де вся логіка складається в одному класі або представленні. Це, мабуть, переважна більшість внутрішніх простих додатків, що працюють на всіх підприємствах.

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

Крім того, як ви вказали, OOP не корисний для всіх сценаріїв. Є й інші моделі.

Незалежно від того, чи є OOP домінуючою моделлю програмування, не має значення, просто покладіть різні моделі на різні випадки.

Срібної кулі немає.

Що Моти Бен Арі сперечається - це академічне твердження, яке вже безглуздо. Однак він заявляє про себе, що ніколи не знаходив OOP, щоб він "мав сенс", очевидно, що це робиться тисячам розробників та інженерів програмного забезпечення, і він використовується в багатьох багатьох системах ...

Але, справді, сенс моєї відповіді полягає в тому, яке корисне твердження про те, що та чи інша модель є домінуючою чи ні, це тоді добре обґрунтування сліпого її використання? Звичайно, це не так.

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

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

Навіть не має сенсу питати, чи корисний ОО, поки відповіді на вищезгадані питання не говорять, не кажучи вже про домінуючі.

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

PS2: Якщо я повинен вибрати / вивчити / використовувати лише один підхід, це OOP чи ні? чому?

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

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

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

Дозволяємо зіткнутися з цим, навіть люди, які розробляють цифрове обладнання, самі дизайнери мікросхем, роблять перехід до дуету SystemVerilog та SystemC. Це об'єктно-орієнтовані мови програмування.

Де OOP не використовувався? Добре, якщо ви кодуєте драйвери пристроїв, важко уявити, для чого вам потрібно загальне програмування або багатократне успадковування АБО, якщо ви використовуєте методи функціонального програмування AI, це значно полегшує роботу. Існує і безліч інших ситуацій, досить сказати, хоча OOP - це досить потужне місце для перебування в олігополістичному світі програмування.

Я б сказав, що ні.

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

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

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

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

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

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

Багато наших "інструментів", які ми використовуємо, базуються на OOP, але вони працюють на ПК, а не в контролері роботів. Сюди входять редактори, моделювання та утиліти.