Czy były badania skuteczności OOP w zarządzaniu złożonością oprogramowania? [Zamknięte]

Zamknięte. To pytanie jest nie na temat . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby było tematem dotyczącym wymiany stosów inżynierii oprogramowania.

Zamknięte 2 lata temu .

OOP jest często uważany za skuteczną strategię zarządzania złożonością oprogramowania, w przeciwieństwie do programowania proceduralnego innego niż OOP.

Czy były jakieś badania sprawdzające to pojęcie? Czy udowodniono, że OOP często pomaga zarządzać złożonością w dużych projektach?

object-oriented case-studies

— Aviv Cohn
źródło

Pomimo bardzo interesujących, IMHO mierzenie „złożoności” i „skuteczności” paradygmatów jest trudnym i podatnym na stronniczość przedsięwzięciem. Każdy program jest wyjątkowy, każdy programista jest wyjątkowy i trudno go porównać. Ponadto produktywność zależy nie tylko od paradygmatu, ale od narzędzi, ekosystemu, materiałów do nauki. Bezstronne badanie powinno pozwolić całym grupom uczniów zaprogramować te same wymagania dla każdego języka i zobaczyć wyniki. Jednak nawet oni prawdopodobnie mają wcześniejszą wiedzę, co czyni ją stronniczą. Nie znam żadnych takich badań.

— Dagnelies

Nie studia, ale jakieś akademickie rant: en.wikipedia.org/wiki/Object-oriented_programming#Criticism

— Den

Jest to trochę podchwytliwe pytanie, ponieważ OOP praktykowane w branży jest zwykle bardzo konieczne. Dlatego przeszliśmy z procedur dotykających globałów do metod modyfikujących obiekty, które modyfikują inne obiekty, które modyfikują inne obiekty; skutki uboczne są nieco bardziej wyraźne, ale wciąż dzieje się dużo akcji na odległość. Z drugiej strony, kiedy minimalizujesz skutki uboczne i czynisz rzeczy niezmiennymi, niektórzy twierdzą, że programujesz funkcjonalnie.

— Doval,

Nie ma sposobu, aby naprawdę go zmierzyć - jest to efekt kwantowy, w którym pomiar wpływa na wynik.

— DeadMG

Aby dokonać porównania, trzeba mieć alternatywny paradygmat, który ma zastosowanie do bardzo dużych systemów programowania, skonstruowanych przez programistów o zwykłych umiejętnościach (tj. Nie przez zespół ekspertów lub najnowocześniejszych naukowców). Duże systemy zwykle obejmują między innymi tworzenie sieci, baz danych, równoważenie obciążenia i redundancję (tj. Niewiarygodne maszyny). Ta ostatnia lista zagadnień dominuje we wszelkich debatach dotyczących paradygmatów języka programowania.

— rwong

Odpowiedzi:

Nie znam żadnych badań z wymiernymi pomiarami. Jak wspomnieli inni w komentarzach do twojego pytania, osiągnięcie tego jest praktycznie niemożliwe. Są jednak dokumenty filozoficzne, które próbują na nie odpowiedzieć.

Mój ulubiony artykuł na ten temat to Out of the Tar Pit Ben Moseley & Peter Marks . Wynika z różnych stwierdzeń z wiarygodnych źródeł o złożonym projekcie systemu do całkiem interesujących wyników.

Out of the Tar Pit stwierdza, że programowanie funkcji jest w rzeczywistości najlepszym paradygmatem do wspierania proponowanych przez nich rozwiązań. Ma to sens, ponieważ z mojego doświadczenia wynika, że złożone systemy OOP z czasem stają się bardzo zbliżone do proceduralnych, a procedury zaczynają wyglądać jak OOP (nie mają składni i innych atrybutów, ale przepływ wykonywania może stać się całkiem podobny). Prawdziwa różnica wynika z innego paradygmatu lub przez połączenie go z OOP. W tej chwili takim paradygmatem jest programowanie funkcjonalne, które w końcu staje się użyteczne w popularnych aplikacjach biznesowych przez zwykłych programistów (wciąż się do nich zbliża).

— Frzng
źródło

Tak, były pewne badania. Oto jeden: http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf

Zasadniczo stwierdza, że nie ma mierzalnej różnicy między produktywnością kodu proceduralnego a produktywnością języka OO .... ale prawda jest taka, że tego rodzaju pytania są tak wrażliwe na kontekst, że żadne badanie nie powie ci, co powinieneś zrobić w danej sytuacji .

— Calphool
źródło

Przez długi czas istniały badania, które wykazały, że wprowadzenie komputerów stacjonarnych do środowiska biurowego nie doprowadziło do zwiększenia wydajności.

@nocomprende, czy masz powód, by sądzić, że te badania były błędne? Komputer osobisty z 1989 roku używany przez przeciętnego pracownika biurowego w 1989 roku całkowicie różni się od nowoczesnej maszyny używanej przez nowoczesnego pracownika. Podobnie zastosowanie technologii obiektowej może z czasem ulec poprawie.

— Jørgen Fogh

@ JørgenFogh Chyba zgadzam się ze stwierdzeniem, że badania nie zawsze pokazują to, co wydaje się być zdrowym rozsądkiem. Firmy nie zaczęłyby używać komputerów w biurach, gdyby pogorszyły sytuację. Ludzie nie spędziliby dziesięcioleci rozwijając podejście OO, gdyby to nie pomogło. Czy oni by zrobili? Cóż, ludzie mogą się mylić, ale jak udowodnić to w taki czy inny sposób? Wszystko sprowadza się do: „Czy to działa dla ciebie ?”