Alternatywa dla programowania obiektowego?


83

OOP jest prawdopodobnie najczęściej używanym paradygmatem programowania w dzisiejszym projektowaniu oprogramowania. Moje pytanie brzmi - jakie inne paradygmaty mogą z nim konkurować i mogą zająć miejsce OOP ? Aby wyjaśnić to pytanie, nie pytam o inne paradygmaty. Jest ich wiele, ale chciałbym wiedzieć, który…

  • Został wykorzystany w praktyce, nie tylko w teorii.
  • Może konkurować z OOP , więc może być używany w dużym projekcie przy minimalnym bólu.
  • Może być używany do tworzenia aplikacji klasycznej z logiką biznesową, bazami danych i tak dalej.
  • Nie jest używany razem z OOP, ale jako zamiennik dla OOP.

A jeśli są jakieś wady / zalety, dlaczego jest lepszy / gorszy od OOP, jakie języki są najlepsze w użyciu, co z używaniem w popularnych językach, czy ma jakieś wzorce projektowe i czy może całkowicie wymienić OOP?


1
@Justin Ardini: Wiem, że jest ich wiele, ale który z nich może konkurować z oop? @Tobiasopdenbrouw & Macros: Ok, zmienione.
Dariusz Woźniak

OOP jest popularny, ponieważ jest popularny, jeśli nie połkniesz koola OOP, nie będziesz miał żadnych projektów do pracy ...
aoeu256

Programowanie zorientowane na dane jest łatwiejsze, gdy zależy Ci na kolekcjach obiektów i ich relacjach, a nie pojedynczych obiektach, gdzie metody „obiektu db” zapewniają hermetyzację. JSON i sexpressions słodzą SQL, CSS, HTML, Excel, skrypty powłoki są popularne i użyteczne, ale „programowanie” oznacza OOP lub procedury. OOP jest wdzięczny za możliwość utrzymania programów Python / JavaScript, mimo że OOP stanowi 20% kodu. Zamknięcia i JSON mogą być używane przez 90% czasu zamiast obiektów i są prostsze i łatwiejsze w użyciu.
aoeu256

Odpowiedzi:


51

Programowanie funkcjonalne to kolejny paradygmat programowania, który jest popularny, głównie w środowisku akademickim. Najlepszym przykładem funkcjonalnego języka programowania jest Haskell i Standard ML .

Podstawowa różnica między programowaniem funkcjonalnym a programowaniem obiektowym polega na tym, że programujesz w sensie przepływu danych, a nie przepływu sterowania . Zobacz prezentację Oswajanie efektów za pomocą programowania funkcjonalnego autorstwa Simona Peyton-Jonesa, która zawiera dobre wprowadzenie.

Dobrym przykładem programowania funkcjonalnego stosowanego w przemyśle jest Erlang . Jest stosowany głównie w systemach telekomunikacyjnych, rozproszonych i odpornych na uszkodzenia. Zobacz prezentację Erlang - oprogramowanie dla współbieżnego świata autorstwa Joe Armstronga .

Istnieją również nowsze języki programowania funkcyjnego, które łączą programowanie funkcjonalne z OOP. Dwa dobre przykłady to F # dla platformy .NET i Scala dla platformy Java; często mogą korzystać z istniejących na platformie bibliotek napisanych w innych językach.

Trendem nowych języków programowania jest teraz Multi-paradygmat , w którym wiele paradygmatów, takich jak programowanie obiektowe i programowanie funkcyjne, jest połączonych w tym samym języku.


4
Scala ma na celu integrację cech języków obiektowych i funkcjonalnych.
Filip

5
Dobra odpowiedź, ale myślę, że programowanie funkcjonalne i programowanie obiektowe to nie dwie strony medalu, mogą one doskonale współistnieć (jak wspomniałeś). To bardziej przypomina to: proceduralne VS Zorientowane obiektowo, imperatywne VS funkcjonalne. Lisp to popularny proceduralny język funkcjonalny, Java to zorientowany obiektowo język imperatywny.
fhd

1
@ ventr1s: Tak, programowanie funkcjonalne może zastąpić OOP, ale najprawdopodobniej będzie używane razem z OOP w językach takich jak Scala i F #.
Jonas

1
@ ventr1s: Dobrym przykładem programowania funkcjonalnego w przemyśle jest rozproszona baza danych NoSQL RIAK napisana w Erlang. riak.basho.com
Jonas

2
@ ventr1s: Zobacz to pytanie dotyczące programowania funkcjonalnego i wzorców projektowych: stackoverflow.com/questions/327955/ ...
Jonas

12

Przetwarzanie proceduralne było wszystkim, zanim pojawiło się OOP, stworzyło kilka dużych aplikacji w świecie rzeczywistym (w rzeczywistości większość z nich pierwotnie) i wiele systemów operacyjnych.

Z pewnością można go stosować w produktach na dużą skalę przy minimalnym bólu i maksymalnej wydajności


4
Tak, a niezliczone badania metryczne wykazały, że kończy się gaz przy około 150 000 LOC. Spójrz na Windows SDK mniej więcej w czasach Petzolda, aby znaleźć traktat o tym, jak programowanie strukturalne rozpada się pod obciążeniem złożoności: funkcje z 8 argumentami, 2 to struktury z 6-10 elementami. Wypychanie danych do i z każdej jednostki obliczeniowej ostatecznie po prostu nie działa.
Rob

2
OK, ale - ile aplikacji ma tak duże rozmiary? Problem z OOP polega na tym, że jest on niezwykle trudny do zrozumienia i zaprojektowany dla rozległych aplikacji - ale jest domyślny nawet dla małych. Ma to odwrotny skutek - niekoniecznie komplikuje mniejszą aplikację.
niico

Programowanie zorientowane obiektowo czasami powoduje, że aplikacje są dłuższe ze względu na potrzebę konstruktorów i długich metod pobierających / ustawiających. Te wczesne języki proceduralne, takie jak C, nie miały wsparcia dla metaprogramowania, żadnego systemu polimorfizmu, zamknięć ani łatwej składni dla reprezentacji JSON / danych ogólnych. C nie obsługiwał nawet opcjonalnych argumentów. Monady i makra mogą być używane do tworzenia potężnych, osadzonych języków specyficznych dla domeny.
aoeu256

Funkcje z 8 argumentami - słyszałeś kiedyś o domyślnych argumentach? A co z proceduralnym + pierwszorzędnym wsparciem dla HashTables + zamknięć, takich jak JavaScript, Python itp.? Mają wiele zalet OOP bez zbyt dużej ilości kodu.
aoeu256

4

Modelowanie relacyjnych danych wektorowych jest wykorzystywane do tworzenia wykonywalnych modeli informacji z semantyką odpowiednią dla domeny w ramach architektury globalnej sieci informacyjnej, brokera modeli rezydujących w sieci.


4

Przede wszystkim należy zauważyć, że wiele obecnie używanych języków programowania (zwłaszcza „języki wyższego poziomu”) to języki wieloparadygmatyczne . Oznacza to, że nigdy nie tworzysz programów, które są wyłącznie OOP (chyba że używasz Smalltalk lub Eiffel, być może do tworzenia dużych projektów).

Spójrz na przykład na PHP :

  • Posiada wiele elementów OOP (od wersji 5)
  • Wcześniej było to głównie proceduralne
  • Posiada elementy programowania deklaratywnego (np. Funkcje tablicowe)
  • Zaimplementowano wiele elementów programowania funkcjonalnego (od wersji 5.4)

Zasadniczo PHP skleja ze sobą wiele różnych paradygmatów (i sam jest „językiem klejenia”).

Również Java implementuje wiele koncepcji, które nie pochodzą z paradygmatu zorientowanego obiektowo (np. Z programowania funkcjonalnego).

Spójrz na listę języków programowania według typu w Wikipedii: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Imperative_languages (nie w 100% dokładne).

Programowanie funkcjonalne (podzbiór programowania dekleratywnego)

  • Wideley używany w praktyce (stał się częścią sklejonych języków takich jak PHP , także Java i wiele innych ma zaimplementowane koncepcje programowania funkcjonalnego)
  • Wiele pomysłów wywodzi się z LISP-a, któremu zdecydowanie warto się przyjrzeć
  • Możesz budować całe aplikacje, np. Z Haskell, dlatego może on "zastąpić" OOP

Programowanie proceduralne

  • C (jako język głównie proceduralny) jest nadal jednym z najczęściej używanych języków
  • Na początku wiele współczesnych języków klejowych było proceduralnych
  • Nadal wiele programów jest w większości proceduralnych (więc jeśli chcesz, może "zastąpić" OOP)

Programowanie logiczne

  • Najbardziej znanym przykładem jest Prolog. Służy do określonych zadań, które korzystają z zapytań logicznych opartych na regułach
  • Nie może „zastąpić” OOP w zakresie budowania dużego projektu, ale może go zastąpić innymi warunkami

Ogólnie języki deklaratywne / specyficzne dla domeny

  • Używasz SQL w swoich projektach? Wtedy nie są one czysto OOP, SQL jest zasadniczo deklaratywny.
  • Wiele języków specyficznych dla domeny (takich jak CSS) jest deklaratywnych

Ogólnie programowanie imperatywne

Ta lista nie jest kompletna, wystarczy, że da pomysł. Zwróć uwagę, że podczas pisania dużej aplikacji zwykle używasz wielu różnych paradygmatów, a nawet każdy używany język implementuje wiele paradygmatów.

OOP jest zwykle uważane za dobry wybór do tworzenia struktury dużych, złożonych relacji podczas modelowania danych. Nie zawsze jest to paradygmat dla wielu innych zadań.


1

FP - Programowanie funkcjonalne to niezwykle popularny paradygmat programowania, który istnieje od bardzo dawna, aw ostatnich latach zaczął zyskiwać na znaczeniu. FP faworyzuje niezmienność nad zmiennością, rekurencją i funkcjami bez skutków ubocznych. Niektóre przykłady popularnych języków FP to między innymi Erlang, Scala, F #, Haskell i Lisp.


-6

Obecnie nie ma paradygmatów, które mogłyby rzeczywiście zastąpić OOP. Problem z (korzyścią) OOP polega na tym, że wykonuje on ogromną pracę za Ciebie - automatyczne zwalnianie zasobów, walidację danych itp. Oraz ułatwia walidację kodu - nie wspominając o tym, że ogromna większość istniejących bibliotek na świecie są napisane w języku OOP, takim jak C ++, C # lub Java. Rzeczywistość radzenia sobie bez tak dużych bibliotek i takich jest wysoce wątpliwa.

W światach niszowych lub akademickich znajdziesz wiele funkcji programowania. Jeśli jednak naprawdę chcesz zrobić duży projekt, jedyną drogą jest OOP.

Myślę, że programowanie ogólne pojawi się jako nowy paradygmat. Jednak wciąż jest w fazie rozwoju i tylko C ++ / D oferuje naprawdę dobre programowanie ogólne.


3
OOP nie robi żadnej z tych rzeczy. Może je ułatwić, ale tylko wtedy, gdy projekt frameworka OO zawiera je, jak w .Net, lub jeśli chcesz je napisać.
Matt Ellen,

Technicznie masz rację. Jednak rzeczywistość jest taka, że ​​wszystkie popularne języki OO obejmują zarządzanie zasobami jako cechę orientacji obiektowej. Trudno byłoby znaleźć język bezpośrednio obsługujący obiekt, który go nie zawiera. OP jest wyraźnie zainteresowany praktyką, a nie teorią.
Puppy

3
zarządzanie zasobami nie jest cechą orientacji obiektowej - zarządzanie zasobami jest cechą imperatywnych języków programowania, które mogą być zorientowane obiektowo lub nie. Nie znam żadnych czysto funkcjonalnych języków, które zmuszają cię do jawnego zarządzania zasobami systemowymi.
Matthew J Morrison,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.