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

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?

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

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

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)

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.

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.

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.

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.

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.

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.

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.

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.