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]

Wg mnie nie chodzi o obiektówkę (którą ja sam olewam często i robię np. publiczne właściwości, bo tak mi wygodnie) a o:
- wzorce projektowe. Nie tylko MVC (o którym wszyscy wiedzą) czy singletony (które są mocno krytykowane) ale np. wzorzec obserwatora, odwrócenie kontroli, adapter, fasada itp. A wzorce obiektowe warto poznać, żeby być lepszym programistą (chociaż niekoniecznie trzeba wszystkich używać na siłę, bo to też błąd).

- decoupling ( bardzo ważne!!!!!!!!!!!!!!!!!!!!!!!!!!!!! niestety pisząc obiektowo można zapomnieć o decouplingu, a to sprawia, że psu na budę taka obiektówka, w zasadzie do wyrzucenia). Czyli uniezależnienie obiektów od innych obiektów, jednych klas od drugich, jednego modułu od drugiego modułu, jednej funkcji od drugiej funkcji. Dobrze zaprojektowany kod obiektowy powinien składać się z klocków, które można bez problemu wymienić na inne. Klasy i obiekty nie powinny być zbytnio sprzężone ze sobą (są wzorce projektowe które pomagają to osiągnąć).

- pragmatyzm - w niektórych podejściach klasyczne OOP się nie sprawdza, np. do małego projektu być może nie ma co się babrać w robienie klas, tylko walnąć parę funkcji, parę tablic i pojechać, bo tak będzie po prostu szybciej. Czasem też może być lepszy Data Driven Design, albo programowanie funkcyjne, które przeżywa ostatnio renesans. Obiektówka nie jest już taka cool jak jeszcze parę lat temu...

- ponowne wykorzystanie kodu (ale tutaj obiektówka nie ma nic do rzeczy. kod może być "obiektowy" a nie nadawać się do ponownego wykorzystania, a kod strukturalny może być dobrze zaprojektowany i służyć przez całe lata. Kwestia designu a nie tego czy ktoś napisze sobie słowo kluczowe "class"). Zresztą moim zdaniem istota programowania obiektowego to wcale nie klasy tylko zasada SOLID
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)