Programowanie obiektowe - jak się przekonać? Opcje

[paramyksowiroza]

Mam prośbę. Czy ktoś mógłby przekonać mnie do programowania obiektowego? OK, jak muszę, to programuję obiektowo, ale strasznie tego nie lubię.

Tak naprawdę, nie znalazłam ani jednego argumentu przemawiającego za tym, że programowanie obiektowe jest LEPSZE.

Dlaczego obiektówka jest lepsza? Wciąż napotykam na opinie, że kod jest prostszy (dla człowieka), że bardziej elastyczny, że uporządkowany. Problem w tym, że ja tego nie widzę. Dlaczego jest prostszy? Jeśli mam plik z funkcjami, to sobie po prostu znajduję funkcję i edytuję. Nie muszę się grzebać w tych wszystkich klasach, szukać, skąd i co dziedziczy i co jest do czego. Co w tym elastycznego? Gdzie tu porządek?

Dziedziczenie? OK, to jest jakiś plus, ale raczej pod kątem ilości kodu, ale nie jego zrozumienia.

Jestem ze starej szkoły. Jak pewnie wielu z Was, moje początki były związane z językiem Quick Basic, Pascal, itp... Może, gdybym zaczynała od razu od podejścia obiektowego, łatwiej byłoby mi to zrozumieć.

Pomoże ktoś?

[PrinceOfPersia]

Ja raczej nie jestem ze starej szkoły, ale trochę czasu już bawię się w php - 2 lata. Nieraz miałem ataki chęci na napisanie czegoś obiektowo i po max godzinie prób i błędów zniechęcam się na kolejne x czasu.

myślę, że nie o to chodzi, żeby się zamykać na obiektówkę, bo to by była ignorancja/noobizm, tylko raczej żeby nie stawiać na piedestale OOP i nie myśleć, że obiektowe programowanie zawsze i wszędzie jest najlepsze, i że całkowicie wystarcza. Czasami warto mieszać paradygmaty, ja np. programując w takich językach jak JavaScript czy Python, programuję niby obiektowo, ale często poszczególne fragmenty piszę w paradygmacie funkcyjnym (nie mylić z proceduralnym!).

Oczywiście naczytałem się teorii programowania obiektowego i rozumiem jego zalety i sens, ale po za aspektem finansowym - jak to napisał kolega wyżej wszędzie teraz wymagają oop i mvc, nie dostrzegam innej motywacji.

a wzorce projektowe? Zrozumienie tego, kiedy warto użyć jakiś wzorzec projektowy, a kiedy inny w sumie może oszczędzić dużo zachodu przy programowaniu - bo nie musisz za każdym razem wymyślać koła na nowo tylko od razu myślisz "o, podzielę kod na Model, Widok i Kontroler, a tu użyję obserwatora". Co prawda żeby użyć MVC nawet obiektówka nie jest potrzebna - ale mimo wszystko jak się czyta coś o wzorcach projektowych to wszystkie przykłady są na OOP, więc i tak łatwiej zrozumieć i zaimplementować w OOP.

Jest w pełni preceduralny, ale pisze go tak, żeby był jak najlepiej poukładany i prosty do edycji. Niemalże wszystko składa się z dobrze napisanych funkcji i wcale nie ma ich tak wiele a strona jest dosyć skomplikowana.

a jakbyś chciał ten projekt podzielić na dwa mniejsze? nie wiem co piszesz, ale załóżmy że jakbyś pisał CMSa, na którym masz
- edycję i dodawania artykułów
- możliwość wysyłania wiadomości prywatnych
- panel do logowania
- forum
itp.
to czy jakbyś np. chciał zrobić drugi projekt, całkiem inny, ale np. chciałbyś, żeby w tym drugim projekcie była możliwość logowania i wysyłania wiadomości prywatnych -- to czy mógłbyś bez problemu bazując na kodzie pierwszego projektu, wydzielić kod odpowiedzialny za logowanie i wysyłanie PW -- a potem zaimportować go do drugiego projektu?

Chodzi mi o to, czy piszesz w sposób modularny - bo jeśli tak, to pewnie nie ma problemu.
Gorzej jak każdy projekt jest jednolitą masą - teoretycznie obiektówka ma temu zapobiegać, bo się dzieli kod na obiekty - ale w praktyce i tak może się zdarzyć, że kod obiektowy również będzie jednolitą masą splątanych ze sobą obiektów, których nie będzie się dało wyjąć z danej aplikacji. Wtedy byś tego kodu nie mógł łatwo wyciągnąć i nie mógłbyś go łatwo użyć w kolejnym projekcie.

Ten post edytował PrinceOfPersia 2.07.2013, 11:19:09