Jakie były historyczne warunki, które spowodowały, że programowanie obiektowe stało się głównym paradygmatem programowania?

Jakie były czynniki ekonomiczne (i inne historyczne), które doprowadziły do ​​tego, że zorientowane obiektowo języki programowania stały się wpływowe? Wiem, że Simula zaczęła, ale czy przyjęcie języków OOP było spowodowane coraz większymi potrzebami biznesu? A może adopcja wynikała bardziej z nowych rzeczy, które można zrobić w językach OOP?

Edytuj Naprawdę najbardziej interesuje mnie to, czy były jakieś czynniki zewnętrzne względem samych języków, które pozwoliły im się przejąć.

Krótka odpowiedź

Myślę, że to była rezygnacja z projektów oprogramowania przed OO. OO pomógł, dodając fundamentalnie krytyczną koncepcję - modelowanie świata rzeczywistego .

Pierwszym zorientowanym obiektowo językiem programowania była Simula w 1967 roku. Jednak w tamtym czasie rozwój oprogramowania w dalszym ciągu znajdował się w laboratoriach i większość paradygmatów była jeszcze bliższa obudowie sprzętowej .

W ciągu całej kolejnej dekady rozwoju oprogramowania dla aplikacji korporacyjnych rozwijały się inne aplikacje komercyjne, a rozwój oprogramowania w ogóle nastąpił przez całe lata siedemdziesiąte. Językami, które przetrwały do ​​dziś w tym wieku (przed 1980 r.) Były C, Cobol, Fortran i podobne. Większość tych języków ma charakter proceduralny. Od tego czasu istniała także Lisp - nie jestem jednak pewien, czy był to wybitny język ogólnego przeznaczenia dla rozwoju komercyjnego. Słynny termin model Wodospad powstał również we wczesnych latach siedemdziesiątych.

W większości środowisk komercyjnych najważniejszym elementem pojawiającym się w rozwoju oprogramowania było zarządzanie projektami. Istnieje pilna potrzeba napiętych i przynajmniej przewidywalnych budżetów oraz zarządzania wymaganiami w celu zamrożenia, aby projekt osiągnął linię mety odpowiednio. W tym okresie był także jednym z mitycznych Manmonthów w 1975 roku.

Wydaje mi się, że pod koniec lat 70. ludzie zostali wypaleni - ponieważ języki proceduralne nie dotrzymały obietnic. I nowy paradygmat Zorientowany obiektowo, który istniał od tego czasu, uczynił go wielkim. Chociaż ludzie mogą się nie zgadzać, myślę, że C ++, który pomaga w znajomości i sprawdzonym doświadczeniu, oraz C, a także obietnica orientacji obiektowej (pierwotnie z nazwą C z klasami) w 1983 roku była kamieniem węgielnym sukcesu programowania obiektowego.

Niektóre odniesienia dla większej perspektywy - http://journal.thedacs.com/issue/43/88

Dlaczego więc OO?

Myślę, że tamte dni (jeśli spojrzysz na punkt widzenia sukcesu projektu) - miało sens, że lepiej zrozumiesz to, co możesz lepiej zrozumieć. Metodologia obiektowa z obietnicą „… wszystko w życiu jest przedmiotem” wydawała się bardziej zdrowa, nawet zanim okazała się znacząca. Praktycznym sukcesem tego czynnika było samo wyobrażenie o wystarczającym wymodelowaniu rzeczywistego świata i problemu przed skokiem z pistoletu - co, jak sądzę, jest czymś zasadniczo nowym, co oferuje OO, czego nie oferował żaden inny paradygmat do tej pory. I zdecydowanie, biorąc pod uwagę, że ten paradygmat zmusił cię do myślenia, zanim kodujesz więcej niż języki proceduralne, pokazał widoczny sukces w zastosowanych projektach oprogramowania i od tego czasu się przyzwyczaił!

EDIT
Dodałbym również, że języki programowania ewoluowały jednocześnie równolegle do tak podstawowych pojęć (paradygmat OO, Aspekt, Maszyny wirtualne). Każda nowa koncepcja i nowe myślenie pojawiło się dopiero, gdy opanowały ją nowe języki programowania - zachowaj tylko znajomość, ale zmień podstawy z rdzeń! Jednocześnie - nowa koncepcja i nowe języki pojawiły się tylko z powodu nowych problemów biznesowych. Lata 80-te - OO dla oprogramowania na dużą skalę, 1990 Java w dobie Internetu, PHP / ASP i wiele innych dla sieci. Innowacje w językach programowania były również napędzane głównie przez nieciągłe potrzeby rynku.

Podsumowując, wczesne lata 80-te były epoką, w której rozpoczęło się komercyjne oprogramowanie na większą skalę - podczas gdy projekty z językami proceduralnymi miały swoje problemy, OO pokazało lepsze światło i sprawiło, że projekty odniosły większy sukces.

Myślę, że największym powodem był sukces graficznych interfejsów użytkownika, takich jak X i Windows. GUI składa się z kilku obiektów, które same zachowują się, co OO jest w stanie dokładnie przedstawić.

Z drugiej strony tekstowy interfejs użytkownika (który nie próbuje przypominać GUI) często po prostu wzoruje się na odpowiedzi na polecenia, który można łatwo zaimplementować w języku proceduralnym. Reguły biznesowe i podobne rzeczy były wdrażane w językach proceduralnych przez dziesięciolecia, bez zbyt wielu problemów, a do dziś wiele programów OO dla aplikacji biznesowych jest raczej proceduralnych; z głupimi obiektami przechowującymi dane i bezstanowymi obiektami zawierającymi reguły biznesowe; pierwsze mogą być zapisy w języku proceduralnym, później mogą być, no cóż, procedury.

Widzę OOP jako naturalny krok ewolucyjny od kodu proceduralnego:

1. Kod proceduralny: Powiedz maszynie, aby zrobiła A, a następnie powiedz, żeby zrobiła B.
2. OOP: Spakuj instrukcje proceduralne w porcje wielokrotnego użytku, definiując interfejsy / wejścia / wyjścia. (Ostrzeżenie: uproszczenie.)

Jestem pewien, że ktoś o szerszym widoku włączy się, ale wygląda na to, że był to naturalny postęp w umożliwieniu programistom szybszego tworzenia kodu: tj. Umożliwieniu większego ponownego wykorzystania kodu.

W tym widoku największym czynnikiem zewnętrznym był obniżony koszt mocy procesora (w porównaniu z kosztem pracy programisty przy tworzeniu typowych programów): narzut obliczeniowy związany z używaniem klas OOP stał się mniej istotny niż oszczędność czasu programisty. (Ten sam kompromis między kosztem procesora a wydatkiem programisty wpłynął na wiele innych aspektów programowania).

Na początku było programowanie imperatywne (jeśli można to tak nazwać). Proste instrukcje, które mówiły komputerowi mainframe, co i jak powinno być obliczane. W tych językach programowania stosowano bezwarunkowe skoki i inne „nieustrukturyzowane” instrukcje, w większości egzotyczne według dzisiejszych standardów.

Potem ktoś wymyślił struktury do programowania. Tymczasem wykonujcie czas i nauczajcie, które znamy dzisiaj. Była to duża innowacja, ponieważ teraz aplikacje o stosunkowo złożonym przepływie mogły być łatwo napisane i zrozumiane. Tak narodziło się programowanie strukturalne.

Potem pojawili się inni ludzie, którzy powiedzieli, że trzeba powtarzać dużo kodu tu i tam i utrzymywanie go było koszmarem, więc należy wynaleźć sposób ponownego użycia kodu. Ludzie wymyślili procedury i funkcje ograniczające fragmenty kodu wielokrotnego użytku. W ten sposób powstały zasady enkapsulacji i zasady pojedynczej odpowiedzialności.

Następnie niektórzy naukowcy powiedzieli, że funkcjonalność powinna być ściśle powiązana z danymi, nad którymi pracuje. Następnie dodali koncepcje dziedziczenia ponownego użycia kodu i polimorfizmu, aby dopasować je do logicznego sposobu, w jaki klasyfikacja działała w prawdziwym życiu. Tak narodziły się języki programowania trzeciej generacji i OOP.