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

14

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ąć.

ihtkwot
źródło
To ma sens, ale chyba bardziej interesowały mnie okoliczności zewnętrzne, które miały miejsce podczas rozwoju. Bardzo dobrze, że czynniki zewnętrzne miały ograniczony wpływ.
Gwarantuję ci, że nawet w przypadku pytania dotyczącego czynników zewnętrznych, programista.stackexchange jest lepszym miejscem. Ma mnóstwo ludzi, którzy aktywnie pracują w branży i wielu, którzy pracują od momentu jej powstania. Prawdopodobnie znajdziesz tam osobę, która ma doskonałą odpowiedź na twoje pytanie niż tutaj.
Opt
2
Smalltalk nie zaczął tego. Simula stworzyła podstawowe pojęcia zorientowania obiektowego. Smalltalk zrobił te pomysły i przekręcił je w zupełnie inny model i nadał nazwę. Warto jednak zauważyć, że żaden język zgodny z modelem Smalltalk OO nigdy nie był tak skuteczny w tworzeniu programów. (Z wyjątkiem Objective-C, który jest szczególnym przypadkiem: Apple spycha go do gardła wszystkich po swojej stronie, ale nikt poza ekosystemem Apple go nie używa). Wszystkie języki OO: C ++, Delphi, Java, C #, itp. użyj modelu Simula.
Mason Wheeler
1
Klocki Lego mogą pasować jako zewnętrzny wpływ ...
Jamie F
1
@Mason: nie jestem pewien, co dzieli modele Simula i Smalltalk. Gdzie położyłbyś Ruby? LUA? Pyton? JavaScript?
kevin cline

Odpowiedzi:

10

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.

Dipan Mehta
źródło
Jakie były cechy zmiany i gdzie się udać? Koniec lat 70. Co sprawiło, że programiści rozumieli, że nadszedł czas, aby odejść? Zmęczony proceduralnie, tak, ale musi być duzin alternatywnych rozwiązań?
Niezależny
@Jonas - ok - poprawił odpowiedź.
Dipan Mehta
Jeśli chodzi o historyczny sukces, który oceniamy - z całą pewnością możemy powiedzieć, że znajomość odgrywa pewną rolę. C (był następcą B), C ++ był lepszym C, mimo że OO podobno była zmianą paradygmatu. Nawet Java była gotowym skokiem z C ++ (który bardziej przypominał C ++ bez problemów z C ++, np. Pamięć i przenośność). Większość tych języków przekroczyła przepaści, efektywniej zdobywając istniejącą przestrzeń, mimo że miały w sobie coś bardziej fundamentalnego. Co więcej, ponieważ każdy język pozyska programistów, którzy znają już inne języki programowania. ALE nie zawsze może to być prawda!
Dipan Mehta
1
Dodałbym również, że języki programowania ewoluowały jednocześnie równolegle z tak podstawowymi pojęciami (paradygmat OO, Aspekt, Maszyny wirtualne). Każda nowa koncepcja i nowe myślenie pojawiły się dopiero, gdy opanowały ją nowe nowe języki programowania - zachowaj tylko znajomość, ale zmień podstawy z rdzenia ! 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.
Dipan Mehta
1
„Modeluj prawdziwy świat” brzmi przekonująco, ale w większości przypadków tak się nie dzieje. CustomerKlasa nie ma metody, takie jak eatLunch, goToWorklub sleep, jeśli to jest to, co klienci zrobić w realnym świecie . ProductKlasa ma kilka metod, choć większość produktów mają dokładnie nie zachowanie w ogóle w świecie rzeczywistym . Dlatego twierdzę, że model OO odpowiada (mniej więcej) właściwościom, ale wcale nie zachowuje się w świecie rzeczywistym. Ale nie potrzebujesz OO, aby mieć model danych, który odpowiada rzeczywistym obiektom. Tylko typy rekordów.
user281377
6

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.

użytkownik 281377
źródło
4

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).

Jamie F.
źródło
2

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.

linkerro
źródło