Kod proceduralny a kod OOP

19

Skończyłem projekt w PHP od 13000+ linii w stylu proceduralnego [bo jestem bardzo obeznany z tym, choć wiem OOP], a projekt działa idealnie.

Ale czy powinienem przekonwertować go na OOP? [ ponieważ świat jest zajęty OOP ]

Mój kod nie potrzebuje żadnej z cechy OOP [hermetyzacja, dziedziczenie w zasadzie ...]!

Więc co powinienem zrobić?

I jaką pomoc otrzymam, jeśli przekonwertuję ją na OOP?

Sourav
źródło
21
Prosimy o informowanie nas, jeśli musisz zmienić ten projekt. Byłoby interesujące dowiedzieć się, jeśli jesteś zadowolony Podjęliśmy tę decyzję albo pożałujesz.
JeffO
2
Potrzebujesz enkapsulacji. OO jest jednym ze sposobów na zdobycie go; może masz inny, który pracuje dla Ciebie, ale ten czy inny sposób trzeba kontrolować zależności kodu.
Marcin
Co powiesz na anegdotę: kilka lat temu pracowałem nad średniej wielkości aplikacją internetową napisaną głównie w JavaScript (nie pytaj). Styl kodowania był w dużej mierze proceduralny. Kiedy projekt dobiegał końca, poczułem się niezadowolony ze sposobu pisania kodu i przepisałem znaczną jego część w OOP-JavaScript. Spowodowało to opóźnienie w realizacji projektu, a my później wykonaliśmy stosunkowo niewielką konserwację projektu. Zawsze zastanawiałem się, czy całe to kodowanie było warte wysiłku ;-)
Pandincus,
tak, było warto. utrzymywanie otwartych drzwi wielokrotnego użytku zawsze jest tego warte.
Chani
1
Pytanie brzmi: czy spodziewasz się dalszego rozwoju? Programowanie proceduralne to najprostszy i najszybszy podejście, gdy wiesz dokładnie, co trzeba, a to nie będzie się zmieniać. Wszelkie zmiany w kodeksie postępowania będą bolesne, w OOP byłoby o wiele łatwiejsze.
Kamil Tomšík,

Odpowiedzi:

52

Mój kod nie potrzebuje żadnej funkcji OOP

Po udzieleniu odpowiedzi na swoje pytanie - jeśli nie trzeba OOP w tym przypadku i projekt pracuje wtedy nie przekształcić go.

Jednak powinieneś rozważyć użycie OOP do następnego projektu - ale tylko jeśli jest to właściwe.

Programowanie proceduralne nie ma w sobie nic złego - o ile jest używane w odpowiednim miejscu.

ChrisF
źródło
2
+1 od zgody „powinieneś rozważyć użycie OOP do następnego projektu”.
Cary Chow,
11
+1 tak, jeśli działa poprawnie, nie naprawiaj tego.
setzamora,
4
Powiedziałbym, że jeśli teraz działa poprawnie, nie zmieniaj go, ale nigdy nie wiesz, jakie będzie następne żądanie funkcji.
JeffO
7
„powinieneś rozważyć użycie OOP do następnego projektu”, ale nie używaj go, chyba że ma to sens. Niektóre rzeczy są lepiej napisane proceduralnie, inne lepiej pasują do OOP. Używaj tego, co jest odpowiednie.
TMN
@TMN - to sugeruje - powinienem wyrazić to jasno.
ChrisF
16

Nie i nie tylko dlatego, że nie potrzebujesz OOP.

Jeśli twój program jest już ukończony i działa zadowalająco, to w ponad 90% przypadków marnowanie czasu na przepisywanie gotowego kodu z jakiegokolwiek powodu jest stratą czasu.

OOP nie jest wszechstronny, istnieje wiele miejsc, w których OOP nie powinien być używany, więc nie używaj go, ponieważ OOP jest trendem.

Skeith
źródło
1
Czy przez „gotowy kod” masz na myśli, że to działa?
JeffO
@eff O tak, proszę pana! jest idealny :)
Sourav,
Powiedział, że zakończył projekt i działa idealnie. Dla mnie oznacza to, że jest on gotowy do dostarczenia klientowi lub został dostarczony do klienta, zakładając, że taki istnieje. Skończone mam na myśli przetestowane i gotowe do wysyłki, oczywiście jeśli pojawią się poważne błędy, może się pojawić przepisanie.
Skeith,
Proszę opracować „wiele miejsc, w których OOP nie powinien być stosowany”.
Falcon
3
@Falcon, bez względu na to jak dobrze zaprojektowane kodu OOP, ale jeśli sama domena problemem jest słabo odwzorowane na modelu OO, projektowania OOP wiąże się brzydko. Istnieje wiele domen problemowych, których nigdy nie należy wyrażać w kategoriach OOP .
SK-logika,
8

Moje ogólne podejście do paradygmatów (i dlaczego żaden z trzech głównych paradygmatów nie jest właściwą ani niewłaściwą metodą programowania):

programowanie proceduralne jest dobra, gdy masz wątpliwości, który jest prosty na wysokim poziomie (choć może być złożony na niskim poziomie) i chce napisać odpowiednio prosty, kod liniowy. Prawdopodobnie łatwiej jest pisać i zrozumieć niż OO i jest funkcjonalny, jeśli problem nie wymaga nigdzie silnego oddzielenia. Przykłady: kod numeryczny, większość małych skryptów, większość małych podproblemów po zepsuciu elementów za pomocą OO lub funkcji.

Kod zorientowany obiektowo jest dobry, gdy trzeba mocno rozdzielić obawy, ponieważ możesz mieć więcej niż jedną implementację niektórych problemów. Przykład: większość oprogramowania dla dużych firm. Możesz na przykład chcieć mocno oddzielić logikę biznesową od logiki prezentacji, ponieważ prawdopodobnie będą musiały zostać zmienione niezależnie.

Programowanie funkcjonalne jest dobre, gdy potrzebujesz silnego oddzielenia mechanizmu od polityki. Posiadanie funkcji mechanizmu, która akceptuje funkcję polityki, jest dobrym wzorcem. (Dowiedziałem się o tym, patrząc na moduł std.algorytm języka programowania D.) Wyodrębnienie stanu zmiennych na granicy między polityką a kodem mechanizmu ogólnie ułatwia zrozumienie API. Jeśli stan zmienny jest używany prywatnie w którymkolwiek z nich, jest to szczegół implementacji. Inną zaletą programowania funkcjonalnego jest współbieżność z oczywistych powodów.

dsimcha
źródło
Dzięki za świetną odpowiedź opisującą każdy typ paradygmatu programowania i podającą przykłady, kiedy / jak go używać.
Kevin Peno,
7

Kod nigdy nie „potrzebuje OOP”. To programiści, o ile potrafią myśleć w różnych trybach, którzy przewidują, że ten lub inny konkretny problem „potrzebuje” $ PARADIGM lub najlepiej go rozwiązać.

Często zdarza się, że programiści znający tylko jeden paradygmat uważają, że ich paradygmat jest największy. Jeden rozmiar pasuje do wszystkich i wszyscy musimy spać w łóżku Procrustesa, jeśli to lub tamto jest obecnie modne.

Ingo
źródło
5

Powinieneś przekonwertować swój projekt na OOP tylko wtedy, gdy istnieje wyraźna oznaka potrzeby OOP. Możliwe scenariusze, w których może się to zdarzyć, to między innymi:

  • powiększanie projektu
  • dodając więcej programistów do zespołu

i nawet w tych scenariuszach może nie być konieczne przekonwertowanie projektu na OOP.

Timothy Groote
źródło
Dobra uwaga, ale czy możesz mi powiedzieć, dlaczego powiększenie projektu lub dodanie większej liczby programistów w zespole będzie problematyczne, jeśli jest to kod proceduralny?
Sourav,
Zwiększenie skali projektu może wymagać dodania złożonych struktur relacyjnych do modelu aplikacji, w takim przypadku przejście do OOP może być opłacalne. Jeśli aplikacja skaluje się krok po kroku i na dłuższą metę okaże się łatwiejsza do zrealizowania lub zrozumienia w OOP, nowi programiści mogą „nadrobić” szybciej, jeśli kod jest OOP. Pozostawienie spuścizny kodu innego niż OO może okazać się problemem później, gdy projekt się powiększy. jeszcze jeden z tych przypadków, w których „rzeczy są takie, jakie są, ponieważ tak się stało”
Timothy Groote
3
właśnie to przyszło mi do głowy, gdy czytam pytanie. mówi, że napisał 13 tys. linii kodu. mam nadzieję, że nie zostanie zmarnowane, używając tylko raz. a jeśli trzeba go ponownie wykorzystać, to oop stałoby się koniecznością. inaczej stałby się koszmarem dla nowych programistów
Chani,
4

Oba mogą być dobre, oba mogą być złe. Ale modernizacja jednego z nich tak, aby wyglądało podobnie, nigdy nie jest dobrym pomysłem.

jwenting
źródło
2

Jeśli przypomnisz sobie, dlaczego OO został wymyślony, zobaczysz, że wcale nie potrzebujesz OOP, ale czasami znacznie ułatwia ci to życie.

W czasach kodowania C bardzo duży program mógł stać się dość niechlujny i trudny w obsłudze. Wymyślili więc sposoby dzielenia go na części modułowe. OOP przyjmuje to podejście i czyni go jeszcze bardziej modułowym, łącząc dane z tymi częściami logiki programu, aby były jeszcze bardziej oddzielone od reszty kodu.

Dzięki temu możesz pisać coraz większe programy, bezpiecznie, że zamiast tego zmieniłeś swojego ogromnego słonia z zadania w sto zadań wielkości myszy. Dodatkową zaletą jest to, że możesz wziąć niektóre z tych „myszy” i użyć ich ponownie w innych programach!

Oczywiście rzeczywisty świat nie jest taki do końca, a ponowne użycie obiektów nigdy nie do końca pasuje do zamierzonego, ale nie oznacza to, że jest to bezużyteczny paradygmat.

Bezużyteczne jest nadmierne poleganie na dowolnym stylu kodowania. Każdy, kto robi OO z tysiącem małych, nieistotnych klas, nie robi tego właściwie - robią koszmar dla siebie (lub kogoś innego). Każdy, kto pisze procedurę, która ma tylko 3 funkcje, również utrudnia życie. Najlepszym sposobem są pośrednie, duże obiekty (czasem nazywane komponentami, do których kiedyś mieliśmy się przyłączyć), które mogą dostarczyć sporo samodzielnego kodu i danych, które są znacznie bardziej prawdopodobne, że zostaną ponownie wykorzystane w oderwaniu od reszty aplikacji.

Moja rada na następny raz: spróbuj napisać zwykły kod proceduralny, ale stwórz pojedynczy obiekt swojej głównej struktury danych. Zobacz, jak uważasz, że praca z nim jest łatwiejsza niż przekazywanie danych z funkcji do funkcji.

gbjbaanb
źródło
0

Mój kod nie potrzebuje żadnej z cechy OOP [hermetyzacja, dziedziczenie w zasadzie ...]!

Skąd to wiesz?

Czy musisz utrzymać ten projekt? Czy planowane są jakieś nowe funkcje? Będą inne osoby, które będą się z tobą rozwijać? Powtórzyłeś się? Czy kod jest trudny do uchwycenia?

Jeśli odpowiedź brzmi „tak”, być może powinieneś zacząć myśleć o założeniu szkieletu OOP i podążaniu tą drogą.

vihus
źródło