[Goryptic]

Może mi ktoś wytłumaczyć jak pięciolatkowi, dlaczego lepsze jest zmienianie prywatnych zmiennych za pomocą publicznych funkcji, zamiast robienie ich od razu publicznymi zmiennymi? Przecież to wychodzi dokładnie na to samo, tylko dłużej i więcej kodu. Przeczytałem wyjaśnienia z pierwszych 10 wyników google i wszystkie sprowadzają się do "kiedyś zrozumiesz jak cośtam". No właśnie chciałbym wiedzieć jakie "cośtam".
#programowanie #cpp

[wnocy]

@Goryptic: wyobraź sobie, że tworzysz klasę, z której ktoś będzie korzystał i ten ktoś to totalny kretyn, którego musisz chronić przed nim samym. Buduj klasę tak, żeby była idiotoodporna. Np. gdy masz pole przechowujące np. temperaturę powietrza, a ktoś wpisze tam 1000 stopni to możesz rzucić wyjątkiem. Możesz też np. chcieć wiedzieć, czy zmienna była ruszana i nie chcesz stosować "magicznych wartości". Wtedy w setterze możesz ustawić flagę informującą o

[c.....o]

@Goryptic: Chodzi o to, żeby użytkownik Twojego API (nawet najprostszej klasy) komunikował się z nim przez ustalony interfejs, a jednocześnie żeby nie mógł zbyt wiele napsuć (enkapsulacja).

Tak naprawdę to zależy od języka. W takiej np. Javie, która nie umie "properties", musisz robić getX() i setX() żeby mieć kontrolę nad stanem wewnętrznym obiektu przy jednoczesnym zachowaniu w miarę sensownego API.
W C# czy Pythonie publiczne "zmienne" są wręcz wskazane, bo:

[Detharon]

@Goryptic: oprócz tego to konieczność jeżeli chodzi o OOP. Tworzysz sobie interfejs Figura i chcesz, żeby każda klasa dziedzicząca po nim musiała zwracać informacje jakiego koloru jest. Żeby to zrobić musisz mieć getColor() w interfejsie, inaczej się po prostu nie da.

W taki sposób stworzysz sobie uniwersalny kod, który będzie działać bez względu na to, jaka dokładnie klasa implementująca ten intefejs się w nim pojawi.

[IntDoubleFloat]

Tak ogólnie to jest to jedna z idei programowania obiektowego, oddzielana jest implementacja od interfejsu.

Tu zdjęcia trzech stron, które to mniej więcej to opisują:
http://imgur.com/a/FwHBk

[devml]

@Goryptic: Jak napisano wyżej, chodzi o możliwość walidacji, także o hermetyzację kodu - w dobrze zaprojektowanym programie obiekt nie powinien wykonywać bezpośrednio operacji na składowych innego obietku.
W praktyce, gdy coś się sypie, w takiej metodzie można ustawić breakpoint i szybko sprawdzić z którego miejsca ta zmienna jest modyfikoowana.

Co ciekawe w gamedevie, w miejscach gdzie ważna jest wydajność, nie jest zalecanie używanie takich metod. Wyobraź sobie np. wywołanie foo.bar++

[MacDada]

@Goryptic:

1. OOP: w programowaniu obiektowym nie interesują Cię dane, tylko możliwość komunikacji. A komunikację zapewniają metody. „Pytasz” o coś (wywołujesz metodę), a nie „sam sobie bierzesz” (odczytujesz pole).

2. Metody mogą być implementacjami interface'ów, pola

[Kaczus2B]

@Goryptic: Choćby po to, aby sprawdzić poprawność wprowadzanych danych, albo po to, że rozbudowując możesz chciec jakąś interakcje przy zmianie wartości tej zmiennej itd...