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]

A doczepiłem sie do tematu dlatego, że wszędzie gdzie się nie czyta o zaletach i wadach obu tych "stylów", to w zdecydowanej większość pisze, że nie da rady napisać coś większego strukturalnie.

ja jestem co prawda za obiektówką, bo jest wygodna i odpowiada mniej więcej temu, jak ja widzę kod (chociaż nie stawiam obiektówki na piedestale, bo to tylko jeden z paradygmatów programowania,), ale przecież masę naprawdę wielkich projektów powstało właśnie w strukturalnie, w języku C, który nawet nie wspiera OOP (chociaż można to emulować). W C można nawet system operacyjny napisać, mimo że nie ma tam żadnych obiektów.

Więc da się.
Chociaż ja podchodzę do tego w ten sposób, że warto poznać praktycznie jak najwięcej paradygmatów i wzorców, żeby wiedzieć, które się najlepiej sprawdzają do danej rzeczy.

Nikiedy jak przeglądam jakieś klasy w oop, to również odnoszę wrażenie - podobnie jak @paramyksowiroza, że ciężej jest poznać ich logikę.

ludzie przesadzają z klasami, właściwościami, metodami. Np. są tacy, którzy do każdej zmiennej prywatnej robią getter i setter, np. getZmienna, setZmienna, getDrugaZmienna, setDrugaZmienna, co już samo w sobie jest złamaniem OOP (bo robienie getterów i setterów do zmiennych, które powinny pozostać prywatne to łamanie zasady enkapsulacj/ukrywania danych).

Przesadza się też z hierarchią i dziedziczeniem, co niestety też zaciemnia kod, jeśli masz 10 stopni hierarchii klas potomnych.