czy OOP jest dominującym modelem programowania w świecie rzeczywistym?

20

Przedmioty nigdy? Cóż, prawie nigdy

W sekcji VIEWPOINT Communications of The ACM znalazłem interesujący artykuł zatytułowany „ Przedmioty nigdy? Cóż, prawie nigdy ”. Jest to zupełnie inna perspektywa niż obiekty - najpierw czy obiekty późno. Sugeruje „przedmioty - nigdy”, a może „przedmioty - ukończenie szkoły”.

Autor mówił o OOP i zadał pytanie, w jaki sposób OOP jest używany w rzeczywistych środowiskach programistycznych. Uważa, że ​​OOP nie jest dominującym modelem programowania. Na przykład, twierdzi, 70% programowań jest wykonywanych dla systemów wbudowanych, w których OOP nie jest tak naprawdę odpowiedni.

Kiedy niektórzy profesorowie uniwersytetów chcą rozmawiać o korzyściach płynących z OOP, mówią o ponownym użyciu kodu. Jako kolejny przykład, ponownie, twierdzi, nie jest to prawdziwy przypadek w prawdziwym świecie. ponowne użycie kodu jest trudniejsze niż twierdzą uniwersytety:

Twierdzę, że stosowanie OOP nie jest tak rozpowszechnione, jak większość ludzi uważa, że ​​nie jest tak skuteczne, jak twierdzą jego zwolennicy, a zatem, że jego centralne miejsce w programie CS nie jest uzasadnione.

Ciekawe jest dla mnie, jak myślą o tym ludzie z przepełnieniem stosu? Czy OOP jest dominującym modelem programowania z punktu widzenia programistów?

Jeśli powinienem wybrać / nauczyć / zastosować tylko jedno podejście, czy jest to OOP, czy nie? czemu?

Ehsan
źródło
26
„70% programowania odbywa się dla systemów wbudowanych”? Czy to na projekt, na programistę czy na LOC? Mam wrażenie, że 70% „wszystkich prorgammingów” odbywa się w programie Excel. Nawet osoby niebędące programistami programują arkusze kalkulacyjne.
LennyProgrammers,
1
@ Lenny222: Jeśli chcesz, zgaduję, że 70% rozproszonych kopii programów jest wbudowanych w oprogramowanie lub coś w tym rodzaju. Teraz niektóre osadzone rzeczy są wykonywane w C ++, a często zhackowana wersja, która pozostawia C i obiekty, więc nie jest słuszne twierdzenie, że osadzone nigdy nie jest zorientowane obiektowo.
David Thornley,
9
Myślę, że dominujący model programowania od dawna był i będzie wielką kulą błota.
whatsisname
Ten artykuł wprowadza dziwne rozróżnienie między „klasami” a „podsystemami”, których nawet nie rozumiem. Mówi o tym, w jaki DiskBrake extends Brakesposób OOP nie nadaje się dla samochodu, ponieważ w „prawdziwym świecie” ta komunikacja jest realizowana „przez sygnały sieciowe i protokoły magistrali” - jak to DiskBrake implements BrakeInterface? Być może to moje własne 43-letnie doświadczenie, ale dla mnie przykłady całkowicie nie potwierdzają twierdzenia autora.
OJFord
2
Link znajduje się teraz za zaporą. W każdym razie OOP jest w pewnym stopniu niedefiniowane i przereklamowane. Powiedzmy jednak, że „większość” nowych programów jest prawdopodobnie pisana w sposób inspirowany Javą w stylu OOP z modułami pobierającymi i ustawiającymi oraz klasami o nazwie SessionManager
Charles Salvia

Odpowiedzi:

19

W sekcji VIEWPOINT w komunikacie ACM

Jeśli interesuje Cię praktyczne programowanie , postępowanie ACM i polubień to ostatnie źródło, które chcesz przeczytać. Są to często publikacje [pseudo] naukowe, bez zastosowania w prawdziwym świecie. Są to często nieortodoksyjne opinie reklamowane, aby autor wyróżniał się z tłumu i promował własną osobę.

Twierdzę, że stosowanie OOP nie jest tak rozpowszechnione, jak większość ludzi uważa, że ​​nie jest tak skuteczne, jak twierdzą jego zwolennicy, a zatem, że jego centralne miejsce w programie CS nie jest uzasadnione.

Nie zgadzam się z twoją tezą. OOP jest szeroko rozpowszechniony i działa dobrze. Pod względem liczby projekty oparte na OOP prawdopodobnie przekroczyły postępy dokonane w innych strategiach (porozmawiajmy o czasach współczesnych, 15-20 lat).

Jednak OOP nie jest srebrną kulą. Działa w przypadku niektórych zmian, nie działa w przypadku innych. Tak jak każde inne podejście.

Ale muszę wspomnieć o tym, że program nauczania powinien przekazywać wiedzę na temat różnych podejść. Jeśli jest oparty na OOP, jest źle. Jeśli jest oparty na FP, jest źle. Powinien obejmować je wszystkie lub w ogóle nie dotykać tego tematu.

PS Po co dbać o to, co dominuje, a co nie? Po prostu weź to, co jest odpowiednie dla danego projektu i pozostaw liczby „badaczom”.


źródło
3
Są to artykuły badawcze z dziedziny informatyki, które jeszcze nie stały się głównym nurtem. Zwykle akademia przefiltrowuje się do prawdziwego świata, choć regularnie.
Orbling
4
@DeveloperArt: Należy pamiętać, że autor artykułu ma 43-letnie doświadczenie w tworzeniu oprogramowania!
Ehsan,
6
Alan Kay dodaje komentarz na cacm.acm.org/magazines/2010/9/… - „Dla kontrastu nigdy nie uważałem, że większość systemów, które nazywają siebie„ obiektowymi ”, jest nawet bliska mojemu znaczeniu, kiedy pierwotnie wymyśliłem termin.' - co wiąże się stycznie z moim postem - „OO? Czyje OO?”
Frank Shearar,
9
@Developer Art: To, co mnie podoba (trochę) za twój post, to część „badaczy”. Ci cholerni naukowcy. Co oni dla nas zrobili? O. Rachunek lambda, zamknięcia, obiekty, programowanie funkcjonalne, ... Ale inny niż to, co już akademicy kiedykolwiek zrobić dla nas?
Frank Shearar,
4
-1 Informatycy potrzebują przestraszonych cytatów? ACM publikuje pseudonaukę? Poważnie?
jprete
17

Jeśli OOP jest jedynym paradygmatem, jaki znasz, być może powinieneś dowiedzieć się więcej. Ale tak naprawdę, co tak naprawdę oznacza OOP? Czy to znaczy Java czy C ++? Czy to znaczy Smalltalk? Czy oznacza to regulowane przedziały wartości i zamknięcia? (Cześć, schemat!) Czy to oznacza wysyłanie wiadomości? (Cześć Erlang!)

Krótko mówiąc, wydaje się, że pytanie jest nieciekawe. „Czy OO jest przydatne ?” to lepsze pytanie. I wydaje się, że w ten sposób. (Z pewnością to jest dla mnie.)

Frank Shearar
źródło
6
+1 Podejrzewam, że w praktyce OOP przestało oznaczać cokolwiek innego niż „dobry sposób pisania kodu, który używa rzeczy zwanych obiektami”.
Larry Coleman,
Artykuł, o którym mowa, nie uważa używania języka OO za gwarancję korzystania z oo i zastanawia się, czy w ogóle powinny istnieć paradygmaty, ponieważ nie istnieją one w innych dyscyplinach inżynierskich.
JeffO,
Być może autor powinien przeczytać Williama Cooka i Matthiasa Felleisena, którzy spędzają dużo czasu, rozmawiając o tym, co jest, a co nie jest tym samym w programowaniu.
Frank Shearar
9

Gdzie są wszyscy programiści wykonujący te „70% programowania”? ze wszystkich programistów, których znam, mniej niż 1% pracuje na systemach Embedded.

Mamy więc 3 opcje:

  1. Jestem wyjątkowa i wszyscy twoi znajomi naprawdę programują osadzone
  2. Gdzieś w piwnicy są armie programistów zamknięte w 70%
  3. ta statystyka została stworzona, a artykuł to bzdury

chyba że zobaczę jakieś dowody, że opcje 1 lub 2 są rzeczywiście prawdziwe, wybieram opcję 3.

(BTW, nie uważam, aby nowoczesne programowanie mobilne było wbudowane, a programowanie mobilne jest często OO, po tym wszystkim, że Apple zmusza cię do użycia * Objective * C do programowania dla iPhone'a)

Nir
źródło
FWIW, poświęciłem kilka sekund i wymyśliłem pół tuzina możliwych środków dla „70% programowania”. Autor mógł równie dobrze wykorzystać siódmy. (Poza tym są tam wbudowani programiści, po prostu nie spędzają czasu w tych samych miejscach i często uważają się za inżynierów elektryków lub coś w tym rodzaju, a nie programistów.)
David Thornley,
1
@David Thornley - kłamstwo ze statystykami wciąż kłamie, autor wyraźnie twierdzi, że przeważająca większość programowania na świecie dotyczy systemów wbudowanych - i mówię, że to całkowita liczba byków # @ $ t, jestem pewien, że mogę wymyślić miara, która pokazuje, że większość programowania na świecie odbywa się w pokoju, w którym się teraz znajduję (dzielę się tylko z jednym innym programistą) - ale wszelkie wnioski, które wyciągnę na podstawie tej obserwacji, będą tak samo bezwartościowe, jak wymyślona miara .
Nir
1
Jestem osadzonym facetem. Widziałem kilka raportów, że około 99% procesorów wyprodukowanych / wysłanych jest dla systemów wbudowanych (jeśli to naprawdę konieczne, mogę wrócić i zacytować raport (y)). Powiedziawszy to, jestem pewien, że prawie 70% całego programowania jest wykonywane dla systemów wbudowanych. Myślę, że około 50% wszystkich dostarczonych procesorów jest 4-bitowych i 8-bitowych, ale prawdopodobnie stanowią one 0,1% (lub mniej) całego programowania. Jak powiedział David, istnieje wiele sposobów wymyślenia „70% programowania”. Nie zdziwiłbym się, gdyby liczba ta wynosiła 20–25%.
Radian
+1 za „kłamstwo ze statystykami wciąż kłamie”; takie prawdziwe, takie prawdziwe…
Donal Fellows
8

Nie mam faktów, które mogłyby podążać za tym, ale OOP nie jest dominującym modelem programowania. Wyobraź sobie wszystkie te wewnętrzne aplikacje opracowane przez kogoś, kto ukończył kurs języka wizualnego lub programował makra w programie Excel.

Wiele aplikacji wykonuje po prostu imperatywne programowanie, w którym cała logika jest ułożona w jedną klasę lub widok. Jest to prawdopodobnie zdecydowana większość wewnętrznych prostych aplikacji działających w całym przedsiębiorstwie.

Nie ma w tym nic złego, istnieje kilka sposobów rozwiązania tego samego problemu. Niektóre są bardziej odpowiednie niż inne.

Również, jak wskazałeś, OOP nie jest przydatne we wszystkich scenariuszach. Istnieją również inne modele.

Morten
źródło
Z drugiej strony może pojawić się pytanie, co należy opisać jako model dominujący. Czy to „ilość aplikacji opracowanych w modelu X”, czy „ilość kodu opracowana w modelu X”? Tak czy inaczej nadal uważam, że OOP nie będzie dominującym modelem.
Morten,
1
+1 Za wysunięcie argumentu, że chociaż OOP może być prawie wszechobecny ze przeszkolonymi profesjonalistami, branża na całym świecie nie do końca to odzwierciedla i istnieje wiele prostych zasad imperatywnych.
Orbling
5

To, czy OOP jest dominującym modelem programowania, nie ma znaczenia, po prostu umieść różne modele w różnych przypadkach.

Nie ma srebrnej kuli.

To, o co kłóci się Moti Ben Ari, to twierdzenie akademickie, które już nie ma znaczenia. Jednak twierdzi on, że nigdy nie odkrył, że OOP ma „sens”, co wyraźnie robi tysiące programistów i inżynierów oprogramowania i był używany w wielu systemach ...

Ale tak naprawdę, sednem mojej odpowiedzi jest to, co dobrego powiedzieć, że taki model jest dominujący, czy nie, czy to dobra uzasadnienie dla ślepego korzystania z niego? Oczywiście, że nie.

ocodo
źródło
Jeśli wiele osób twierdzi, że używa jednego modelu, a nie, to jest problem. Pytanie jest tak powszechne, jak się wydaje, i nie dotyczy dominacji / lepszego.
JeffO
4

Na to pytanie trudno odpowiedzieć w sposób wiarygodny. Największym powodem są ludzie tacy jak ja, którzy pracują w niestandardowych aplikacjach wewnętrznych, w których kod nigdy nie opuszcza naszego budynku. Czy używamy tutaj OO? Nie mówię. Ilu innych programistów ma podobne prace? Oni też nie mówią. Mamy witryny z ofertami pracy, ale nie wszystkie oferty są publikowane i nie wszystkie oferty dotyczą prawdziwych ofert, w przeciwieństwie do osób rekrutujących próbujących zebrać listy nazwisk.

Nawet jeśli powiedziałem, że używamy OO tam, gdzie pracuję, czy to oznacza tradycyjną definicję z połączonego artykułu: Przedmioty, Klasy, Dziedziczenie? Czy oznacza to, że używam obiektów przede wszystkim do organizowania kodu? Czy to oznacza, że ​​tak naprawdę programuję tylko interfejsy i wcale nie używam dziedziczenia? Nadal nie mówię, ale który z nich naprawdę liczy się jako OO?

Nie ma nawet sensu pytać, czy OO jest przydatne, dopóki nie zostaną udzielone odpowiedzi na powyższe pytania, a tym bardziej dominujące.

Larry Coleman
źródło
2

Oczywiście, że tak, ponieważ jest to najnowsze hasło, do którego kierownictwo się przyczepiło. Oferuje także lepszą enkapsulację i abstrakcję niż programowanie imperatywne, więc myślę, że przejście od oop do tego, co nastąpi później, może potrwać nawet dłużej niż imperative do oop.

PS2: Jeśli powinienem wybrać / nauczyć / zastosować tylko jedno podejście, czy jest to OOP, czy nie? czemu?

Jeśli chcesz się tylko uczyć, wybierz inną dziedzinę.

Powinieneś dowiedzieć się o typach i enkapsulacji oraz wszystkich innych zaletach OOP, a następnie nauczyć się, jak osiągnąć te same rzeczy za pomocą funkcjonalnego stylu programowania.

Josh
źródło
+1 za komentarz dotyczący wyboru innego pola, jeśli planujesz nauczyć się jednego podejścia. To jest szalone.
Mat Nadrofsky
1

OOP jest zdecydowanie jednym z bardziej dominujących modeli programowania w świecie rzeczywistym.

Spójrzmy prawdzie w oczy, nawet ludzie, którzy projektują sprzęt cyfrowy, sami projektanci układów dokonują przejścia do duetu SystemVerilog i SystemC. Są to zorientowane obiektowo języki programowania.

Gdzie nie można stosować OOP? Cóż, jeśli kodujesz sterowniki urządzeń, trudno sobie wyobrazić, dlaczego potrzebujesz ogólnego programowania lub wielokrotnego dziedziczenia LUB, jeśli wykonujesz techniki programowania funkcjonalnego AI, znacznie ułatwia to sobie zadanie. Istnieje również wiele innych sytuacji, wystarczy powiedzieć, że OOP to dość potężne miejsce, aby być w oligopolistycznym świecie programowania.

Fanatyk 23
źródło
1

Powiedziałbym nie.

Rozumiem, że istnieje ogromna ilość kodu, który jest napisany przy użyciu języka „obiektowego”, ale ogólnie uważam, że kod jest po prostu proceduralny zawarty w klasach. (nie to, że jest to zła rzecz). Kod, który widziałem, który jest napisany, aby był bardziej OO w tych językach, jest okropnym bałaganem zależności między klasami, którego zwykle nie da się utrzymać.

OO powinno polegać na przekazywaniu wiadomości między całkowicie samowystarczalnymi obiektami, i widzimy to w dzisiejszym kodzie, ale na znacznie bardziej szczegółowym poziomie - tzn. Widzimy te obiekty zaimplementowane jako dll lub zespoły lub obiekty COM. „Komponenty” Słyszałem, jak je opisano jako.

więc myślę, że tak naprawdę nie ma znaczenia, czy OO jest używane, czy nie - jeśli kod jest możliwy do utrzymania w trakcie jego życia, do ponownego użycia w stopniu, w jakim został zaprojektowany, i szybkiego rozwoju, to mnie to nie obchodzi jeśli jest to czysto proceduralne lub zorientowane półobiektywnie lub całkowicie OO. Wątpię, czy ktokolwiek może powiedzieć, czy dominujący styl jest jednym z nich, ale zaryzykuję przypuszczenie, że styl proceduralny będzie najczęstszy, nawet jeśli zostanie podzielony na klasy zamiast funkcji.

gbjbaanb
źródło
0

Myślę, że ważne jest różnicowanie rozwiązania uzyskanego poprzez zastosowanie podejścia zorientowanego obiektowo i rozwiązania zaimplementowanego przy użyciu paradygmatu zorientowanego obiektowo. Moim zdaniem na temat dobrego oprogramowania obiektowego jest połączenie obu rozwiązań. Jeśli myślisz o obiektach i szanujesz definicje obiektów i interakcje, a problem można dostosować do korzystania z tej struktury, będziesz mieć kod, który jest elastyczny i niezawodny. Ale jeśli użyjesz obiektów do rozwiązania kodu za pomocą paradygmatu proceduralnego, skończysz z nieprzyjemną mieszanką, która nie skorzysta z zalet Objects.

Naprawdę wolę, aby mój kod był zorientowany obiektowo i zdałem sobie sprawę, że na początku tworzenie dobrej struktury może być nieco bardziej irytujące, ale jeśli chodzi o elastyczność i wymagania klienta dotyczące flashowania dzisiaj, myślę, że warto wysiłek.

guiman
źródło
0

Nie udaję, że znam dokładne liczby, ani nawet nie zgaduję, ale istnieje wiele projektów programistycznych, które nie wymagają OOP. Pracuję z robotami przemysłowymi. Programy są zwykle dość prostym i bezpośrednim kodem proceduralnym. Rzeczywisty system operacyjny robota jest tym bardziej jeszcze.

Wiele naszych „narzędzi”, których używamy, jest opartych na OOP, ale działają na komputerach PC, a nie na sterowniku robota. Obejmują one edytory, symulacje i narzędzia.

Jim C.
źródło