Czy programowanie proceduralne ma jakąś przewagę nad OOP?

Lubię Glass ' Zasady 3, jeśli chodzi o ponowne użycie (co wydaje się być tym, co Cię interesuje).

1) jest to 3 razy trudniejsze do buduj komponenty wielokrotnego użytku jako pojedyncze używaj komponentów
2) wielokrotnego użytku komponent należy wypróbować w trzech różne aplikacje, zanim będzie być wystarczająco ogólne, aby przyjąć do biblioteka reuse

Z tego myślę, że można ekstrapolować te Corolle

A) jeśli nie masz budżet za 3 razy tyle czasu, ile ci to zajmie aby zbudować komponent jednorazowego użytku, może powinieneś wstrzymać się z ponownym użyciem. (Zakładając Trudność = Czas)
b) Jeżeli nie masz 3 miejsc gdzie byś użyj komponentu, który budujesz, może powinieneś wstrzymać się z budową komponent wielokrotnego użytku.

Nadal uważam, że OOP jest przydatny do budowania komponentu jednorazowego użytku, ponieważ zawsze można go przekształcić w coś, co jest naprawdę wielokrotnego użytku później. (Można również refaktorować od PP do OOP, ale myślę, że OOP ma wystarczająco dużo korzyści w zakresie organizacji i enkapsulacji, aby tam zacząć) {]}

Reusability (lub jej brak) nie jest związana z żadnym konkretnym paradygmatem programowania. Używaj programowania obiektowego, proceduralnego, funkcjonalnego lub dowolnego innego w razie potrzeby. Organizacja i możliwość ponownego użycia wynikają z tego, co robisz, a nie z narzędzia.

Sam dałeś odpowiedź-duże projekty po prostu potrzebują OOP, aby zapobiec zbytniej bałaganie.

Z mojego punktu widzenia największą zaletą OOP jest organizacja kodu. Obejmuje to zasady suszenia i hermetyzacji.

Ci, którzy religijnie wspierają OOP, nie mają żadnych faktów, które uzasadniałyby ich poparcie, co widzimy również w tych komentarzach. Są szkoleni (lub myją mózg) na uniwersytetach, aby używać i chwalić tylko OOP i OOP i dlatego wspierają go tak ślepo. Czy w ogóle wykonali jakąś prawdziwą pracę w PP? Inne niż ochrona kodu przed nieostrożnymi programistami w środowisku zespołowym, OOP nie oferuje zbyt wiele. Osobiście pracując od lat zarówno w PP jak i OOP uważam, że PP jest prosty, prosty i bardziej efektywny, a ja zgadzam się z następującymi mędrcami i kobietami:

(odniesienie: http://en.wikipedia.org/wiki/Object-oriented_programming):

Wielu znanych badaczy i programistów skrytykowało OOP. Oto lista niepełna:

• Luca Cardelli napisał pracę zatytułowaną "Bad Engineering Properties of Object-Oriented Languages".

• Richard Stallman napisał w 1995 roku: "dodanie OOP do Emacsa nie jest wyraźnie ulepszeniem; użyłem OOP podczas pracy nad systemami okien maszyn Lisp i nie zgadzam się ze zwykłym poglądem, że jest to lepszy sposób na programowanie."

• Badania Potoka i in. nie wykazano znaczącej różnicy w wydajności między podejściem OOP a podejściem proceduralnym.

• Christopher J. Date stwierdził, że krytyczne porównanie OOP do innych technologii, w szczególności relacyjnych, jest trudne z powodu braku uzgodnionej i rygorystycznej definicji OOP. Podstawy teoretyczne na OOP jest proponowany, który wykorzystuje OOP jako rodzaj konfigurowalnego systemu typu do obsługi RDBMS.

• Alexander Stepanov zasugerował, że OOP zapewnia matematycznie Ograniczony punkt widzenia i nazwał go "prawie tak samo mistyfikacją jak sztuczna inteligencja" (prawdopodobnie odnosząc się do projektów sztucznej inteligencji i marketingu z lat 80., które są czasami postrzegane jako nadgorliwe z perspektywy czasu).

• Paul Graham zasugerował, że celem OOP jest działanie jako " pasterstwo mechanizm", który chroni przeciętnych programistów w przeciętnych organizacjach przed"wyrządzaniem zbyt dużych szkód". Dzieje się to kosztem spowolnienia produktywnych programistów, którzy wiedzą, jak korzystać z mocniejszych i bardziej kompaktowych technik.

• Joe Armstrong, główny wynalazca Erlanga, cytuje: "problem z językami zorientowanymi obiektowo polega na tym, że mają całe to Ukryte środowisko, które noszą ze sobą. Chciałeś banana, ale masz goryla trzymającego banan i cała dżungla."

• Richard Mansfield, autor i były redaktor COMPUTE! magazyn stwierdza ,że " podobnie jak niezliczone mody intelektualne na przestrzeni lat ("trafność", komunizm," Modernizm " itd.-Historia jest nimi zaśmiecona), OOP będzie z nami, aż w końcu rzeczywistość się potwierdzi. Ale biorąc pod uwagę, jak OOP obecnie przenika zarówno uniwersytety i miejsca pracy, OOP może również okazać się trwałym złudzeniem. Całe pokolenia indoktrynowanych programiści nadal maszerują z Akademii, zobowiązani do OOP i nic poza OOP do końca życia.", a także jest cytowany jako powiedzenie "OOP jest do pisania programu, co przechodzenie przez ochronę lotniska jest do latania".

Myślę, że sucha zasada (nie powtarzaj się) w połączeniu z odrobiną zwinności jest dobrym podejściem. Buduj swój program stopniowo, zaczynając od najprostszej rzeczy, która działa, a następnie dodawaj funkcje jeden po drugim i ponownie uwzględniaj kod w razie potrzeby.

Jeśli znajdziesz się pisząc kilka tych samych linijek kodu raz za razem-może z różnymi danymi-nadszedł czas, aby pomyśleć o abstrakcjach, które mogą pomóc oddzielić rzeczy, które się zmieniają od rzeczy, które pozostają to samo.

Utwórz dokładne testy jednostkowe dla każdej iteracji, aby można było ponownie Współczynnik z pewnością.

Błędem jest spędzanie zbyt dużo czasu na przewidywaniu, które części kodu muszą być wielokrotnego użytku. Wkrótce stanie się to oczywiste, gdy system zacznie rosnąć.

W przypadku większych projektów z wieloma zespołami deweloperskimi musisz mieć jakiś plan architektoniczny, który poprowadzi rozwój, ale jeśli pracujesz samodzielnie lub w małej spółdzielni zespół wtedy Architektura pojawi się naturalnie, jeśli trzymać się zasady suchej.

Kolejną zaletą tego podejścia jest to, że cokolwiek robisz, opiera się na prawdziwym doświadczeniu świata. Moja ulubiona analogia - musisz pobawić się cegłami, zanim będziesz mógł sobie wyobrazić, jak może być zbudowany budynek.

Jeśli projekt jest tak mały, że byłby zawarty w jednej klasie i nie będzie używany zbyt długo, rozważyłbym użycie funkcji. Alternatywnie, jeśli używany język nie obsługuje OO (np. c).

Myślę, że powinieneś używać stylu proceduralnego, gdy masz bardzo dobrze określony problem, Specyfikacja nie zmieni się i chcesz bardzo szybko uruchomiony dla niego program. W takim przypadku możesz wymienić konserwację na wydajność.

Zwykle tak jest, gdy piszesz silnik gry lub naukowy program symulacyjny . Jeśli twój program obliczy coś więcej niż milion razy na sekundę, powinien być zoptymalizowany do edge.

Możesz używać bardzo wydajnych algorytmów, ale nie będzie to wystarczająco szybkie, dopóki nie zoptymalizujesz użycia pamięci podręcznej. Może to być duży wzrost wydajności Twoje dane są buforowane. Oznacza to, że procesor nie potrzebuje pobierać bajtów z pamięci RAM, zna je. Aby to osiągnąć, należy starać się przechowywać dane blisko siebie, Rozmiar pliku wykonywalnego i danych powinien być minimalny, i spróbuj użyć jak najmniej wskaźników, jak możesz (użyj statycznych globalnych tablic o stałej wielkości, gdzie możesz sobie pozwolić).

Jeśli używasz wskaźników ciągle skaczesz w pamięci, a Twój procesor musi za każdym razem przeładowywać pamięć podręczną. Kod OOP jest pełen wskaźników: każdy obiekt jest przechowywany przez jego adres pamięci. Wywołujesz new wszędzie, które rozprzestrzeniają się po całej pamięci, co praktycznie uniemożliwia optymalizację pamięci podręcznej(chyba że masz alokator lub garbage collector, który utrzymuje rzeczy blisko siebie). Wywołujesz połączenia zwrotne i funkcje wirtualne. Kompilator zwykle nie może wbudować funkcji wirtualnych i wirtualnego wywołanie funkcji jest stosunkowo powolne (Skocz do VMT, Uzyskaj adres wirtualnej funkcji, wywołaj ją [wymaga to wypchnięcia parametrów i zmiennych lokalnych na stos, wykonania funkcji, a następnie wybrania wszystkiego]). Ma to duże znaczenie, gdy masz pętlę działającą od 0 do 1000000 25 razy w każdej sekundzie. Za pomocą stylu proceduralnego nie ma funkcji wirtualnej i optimizar może inline wszystko w tych hot pętli.

Te dwa pojęcia nie wykluczają się wzajemnie, jest bardzo prawdopodobne, że będziesz używał PP w połączeniu z OOP, nie widzę, jak je segregować.

Myślę, że przydatność OOP zależy bardziej od obszaru tematycznego, w którym pracujesz, niż od wielkości projektu. Istnieją pewne obszary tematyczne (CAD, modelowanie Symulacyjne itp.), gdzie OOP w sposób naturalny odwzorowuje związane z nimi pojęcia. Jednak istnieje wiele innych dziedzin, w których mapowanie kończy się niezdarnym i niezgodnym. Wiele osób używających OOP do wszystkiego wydaje się spędzać dużo czasu próbując wbić kwadratowe kołki w okrągłe otwory.

OOP ma swoje miejsce, ale tak samo jak proceduralne Programowanie, Programowanie funkcyjne itp. Spójrz na problem, który próbujesz rozwiązać, a następnie wybierz paradygmat programowania, który pozwoli Ci napisać najprostszy możliwy program, aby go rozwiązać.

Jednym z celów OOP było ułatwienie ponownego użycia, jednak nie jest to jedyny cel. Kluczem do nauki efektywnego wykorzystania obiektów są wzorce projektowe.

Wszyscy jesteśmy przyzwyczajeni do idei algorytmów, które mówią nam, jak łączyć różne procedury i struktury danych, aby wykonywać wspólne zadania. Z drugiej strony spójrz na wzorce projektowe grupy czterech, aby znaleźć pomysły, jak łączyć przedmioty w celu wykonywania wspólnych zadań.

Zanim dowiedziałem się o wzorcach projektowych, byłem całkiem dużo w ciemności o tym, jak efektywnie wykorzystywać obiekty inne niż jako super struktura typu.

Pamiętaj, że implementacja interfejsów jest równie ważna, jeśli nie ważniejsza niż dziedziczenie. W tamtych czasach C++ był wiodącym przykładem programowania obiektowego i używanie interfejsów jest zasłonięte w porównaniu do dziedziczenia (funkcje wirtualne, itp.). Dziedzictwo C++ oznaczało, że dużo większy nacisk położono na zachowanie ponownego użycia w różnych samouczkach i szerokich przeglądach. Od tego czasu Java, C#, a inne języki przeniosły interfejs do większej ostrości.

Interfejsy są świetne do precyzyjnego definiowania interakcji dwóch obiektów z każdym. Nie chodzi o ponowne wykorzystywanie zachowań. Jak się okazuje, wiele z naszego oprogramowania dotyczy interakcji różnych części. Tak więc korzystanie z interfejsu daje o wiele większy wzrost produktywności niż próba tworzenia komponentów wielokrotnego użytku.

Pamiętaj, że podobnie jak wiele innych pomysłów programistycznych obiekty są narzędziem. Będziesz musiał wykorzystać swój najlepszy osąd co do tego, jak dobrze, że pracują dla Twojego projektu. Dla mojego oprogramowania CAD/CAM do maszyn do cięcia metalu istnieją ważne funkcje matematyczne, które nie są umieszczane w obiektach, ponieważ nie ma powodu, aby były w obiektach. Zamiast tego są one eksponowane z biblioteki i używane przez obiekt, który ich potrzebuje. Następnie istnieją pewne funkcje matematyczne, które zostały zorientowane obiektowo, ponieważ ich struktura naturalnie prowadzi do tego ustawienia. (Pobieranie listy punktów i przekształcanie jej w kilka różnych typów ścieżek cięcia). Again wykorzystaj swój najlepszy osąd.

Część odpowiedzi zależy od tego, jakiego języka używasz. Wiem, że w Pythonie przeniesienie kodu proceduralnego do klasy lub bardziej formalnego obiektu jest dość proste.

Jedna z moich heurystyk jest oparta na "stanie" sytuacji. Jeśli procedura zanieczyszcza przestrzeń nazw lub może wpłynąć na stan Globalny (w zły lub nieprzewidywalny sposób), to zamknięcie tej funkcji w obiekcie lub klasie jest prawdopodobnie rozsądne.

Programy proceduralne mogą być prostsze dla określonego typu programów. Zazwyczaj są to krótkie programy podobne do skryptów.

Rozważ ten scenariusz: Twój kod to nie OO. Masz struktury danych i wiele funkcji w całym progam, które działają na strukturach danych. Każda funkcja przyjmuje strukturę danych jako parametr i robi różne rzeczy w zależności od pola "data_type" w strukturze danych.

Jeśli wszystko działa i nie zostanie zmienione, kogo obchodzi, czy to OO, czy nie? To działa. Zrobione. Jeśli można dojść do tego punktu szybciej pisząc, to może w ten sposób idź.

Ale czy na pewno tego nie zmienisz? Załóżmy, że prawdopodobnie dodasz nowe typy struktur danych. Za każdym razem, gdy dodajesz nowy typ struktury danych, na którym mają działać te funkcje, musisz upewnić się, że znajdujesz i modyfikujesz każdą z tych funkcji, aby dodać nowy przypadek "else if", aby sprawdzić i dodać zachowanie, które chcesz mieć wpływ na nowy typ struktury danych. Ból ten wzrasta, jak program staje się większy i bardziej skomplikowane. Im bardziej prawdopodobne jest to im lepiej, tym lepiej.

I-jesteś pewien , że działa bez błędów? Bardziej zaangażowana logika przełączania tworzy większą złożoność testowania każdej jednostki kodu. Z polymorphic wywołania metod, Język Obsługuje logikę przełączania dla Ciebie i każda metoda może być prostsze i prostsze do przetestowania.

Wierzę, że Grady Booch powiedział kiedyś, że naprawdę zaczynasz dużo korzystać z OOP przy 10000 + linijkach kodu.

Zawsze zaczynam projektować odgórnie, a w górnych partiach dużo łatwiej jest myśleć w kategoriach OOP. Ale kiedy przychodzi czas na zakodowanie niektórych małych konkretnych części, jesteś o wiele bardziej produktywny dzięki programowaniu procedur. OOP jest fajny w projektowaniu i kształtowaniu projektu, dzięki czemu można zastosować paradygmat divide-et-impera. Ale nie można go stosować w każdym aspekcie kodu, ponieważ była to religia:)

Jeśli "myślisz OO" podczas programowania, to nie jestem pewien, czy ma sens pytać "kiedy powinienem wrócić do programowania proceduralnego?"Jest to równoznaczne z pytaniem programistów Javy, czego nie mogą zrobić, ponieważ java wymaga klas. (Języki.NET).

Jeśli musisz się postarać, aby zapomnieć o proceduralnym myśleniu, radzę zapytać, jak możesz to przezwyciężyć (jeśli chcesz); w przeciwnym razie pozostań przy proceduralnym. Jeśli to tyle wysiłku, aby dostać się do OOP-mode, Twój kod OOP prawdopodobnie nie będzie działał zbyt dobrze i tak (dopóki nie przejdziesz dalej wzdłuż krzywej uczenia się.)

"problem z językami obiektowymi polega na tym, że mają całe to Ukryte środowisko, które noszą ze sobą. Chciałeś banana, ale dostałeś goryla trzymającego banana i całą dżunglę."- Joe Armstrong

Większość badań wykazała, że kod oo jest bardziej zwięzły niż kod proceduralny. Jeśli spojrzysz na projekty, które przepisują istniejący kod C w C++ (nie coś, co koniecznie radzę, BTW), zwykle widzisz zmniejszenie rozmiaru kodu między 50 a 75 procent.

Więc odpowiedź brzmi - Zawsze używaj OO!

IMHO, długoterminowe korzyści z OOP przewyższają czas zaoszczędzony w krótkim okresie.

Jak powiedział AZ, używanie OOP w sposób proceduralny (co robię dość często), jest dobrym sposobem (dla mniejszych projektów). Im większy projekt, tym więcej OOP powinieneś zatrudnić.

W obu koncepcjach można pisać złe oprogramowanie. Mimo to złożone oprogramowanie jest znacznie łatwiejsze do napisania, zrozumienia i utrzymania w językach oo niż w językach proceduralnych. Pisałem bardzo złożone aplikacje ERP w języku proceduralnym (Oracle PL/SQL), a następnie przerzuciłem się na OOP (C#). To był i nadal jest powiew świeżego powietrza.

Moje dwa centy...

Zalety programowania proceduralnego

• Proste projektowanie (szybki dowód koncepcji, walka z dramatycznie wymagania dynamiczne)
• prosta komunikacja między projektami
• naturalne, gdy porządek czasowy ma znaczenie
• mniej kosztów w czasie pracy

Im bardziej Kod proceduralny staje się dobry, tym bliżej jest funkcjonalny. Zalety FP są dobrze znane.