Kod proceduralny a kod OOP

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?

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.

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.

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.

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.

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.

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.

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.

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