Чи проводилися дослідження ефективності ООП в управлінні складністю програмного забезпечення? [зачинено]

Зачинено. Це питання поза темою . Наразі відповіді не приймаються.

Хочете вдосконалити це питання? Оновіть питання, щоб воно було тематичним для обміну стеками програмного забезпечення.

Закрито 2 роки тому .

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

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

object-oriented case-studies

— Авів Кон
джерело

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

— dagnelies

Чи не дослідження, але деякі академічні просторікування: en.wikipedia.org/wiki/Object-oriented_programming#Criticism

— Den

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

— Doval

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

— DeadMG

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

— rwong

Відповіді:

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

Моя улюблена стаття на цю тему - «Близько смоляної ями» Бен Мозелі та Пітер Маркс . Це пояснюється різними твердженнями з поважних джерел щодо складної системи проектування до досить цікавих результатів.

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

— frzng
джерело

Так, були деякі дослідження. Ось один: http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf

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

— Calphool
джерело

Тривалий час проводилися дослідження, які показали, що впровадження настільних комп’ютерів в офісне середовище не призводить до підвищення продуктивності праці.

@nocomprende Чи є у вас підстави вважати, що ці дослідження зробили неправильний висновок? ПК з 1989 року, який використовував середній офісний працівник 1989 року, абсолютно відрізняється від сучасної машини, якою користується сучасний працівник. Аналогічно, застосування об’єктної технології з часом може або не може покращуватися.

— Jørgen Fogh

@ JørgenFogh Я думаю, що я погоджувався із твердженням, що дослідження не завжди показують те, що здається здоровим глуздом. Підприємства не почали б використовувати комп’ютери в офісах, якби вони погіршили ситуацію. Люди не витратили б десятиліття на розробку підходу ОО, якби це не допомогло. Вони б? Ну, люди можуть помилятися, але як ви доказово це так чи інакше докажете? Що зводиться до цього: "Це працює для вас ?"