operatory widoczności - po co

Witam
Mam takie teoretyczne pytanie do ludzi bardziej doświadczonych.

W książkach zawsze mamy napisane, że jest coś takiego jak private, public, protected ale zawsze można zrobić to samo nie używając tych operatorów. Autorzy nie piszą jakie jest zastosowanie w praktyce i w czym to tak na prawdę się przydaje, po co ograniczać dostęp.

Czytając różne materiały, kody źródłowe, często napotykam się na funkcje typu set() i get() zmieniające zmienne prywatne.
Po co tworzyć takie funkcje skoro to samo możemy zrobić jeśli ta zmienna jest publiczna wpisując obiekt.x=wartość. I tak i tak zmieniamy jej wartość więc po co utrudniać sobie życie funkcjami?
Do tego mając operatory widoczności - rozumiem, że jeśli klasa jest gigantyczna i ktoś z niej miałby korzystać to może by się do tego przydały ale (mając moje małe doświadczenie) jakoś tego nie czuję. Mam klasy i wiem co w nich jest i równie dobrze wszystko mogłoby być publiczne i na tym bym operował. Mógłby mi ktoś, kto pisał jakieś duże projekty powiedzieć jakie to ma realne i praktyczne zastosowanie ?

Pozdrawiam

Napisz program, w którym będziesz miał kilka współpracujących ze sobą klas i dziedziczenie, to zrozumiesz.

Ja to zrozumiałem dopiero jak napisałem jakąś karcianke w C++.. Spróbuj, może też zrozumiesz:) Czasami będziesz chciał, żeby jakiś atrybut był tylko do odczytu, albo tylko do zapisu.. Tutaj już chyba widzisz po co private i metody? Niektóre metody, albo zmienne nie muszą być pokazywane na światło dzienne i potrzebujemy je wywoływać z wewnątrz klasy. Po co pokazywać takie metody czy zmienne? Gdy mamy jasno ustalone, co chcemy pokazywać a co nie, wiemy co jest dla nas istotne i możemy zając się tylko i wyłącznie wysyłaniem komunikatów do obiektów, nie martwiąc się tym co mają pod maską..

Sprawa jest prosta: co nie jest zabronione jest dozwolone, a twoi koledzy z zespołu będą to nadużywać.

A get() i set() są potrzebne do wielu rzeczy, np efektywnej implementacji mapowania obiekty - baza danych. W setterze można np ustawiać dodatkową flagę, że pole się zmieniło, a potem aktualizować w bazie tylko to pole, zamiast zapisywać cały obiekt od nowa, gdy tylko to jedno pole się zmieniło. Oczywiście bardzo często gettery i settery np w Javie mają trywialną, ale rozwlekłą strukturę, ale na szczęście można to zredukować za pomocą np Project Lombok. No chyba, że chodzi ci o inny język.

@tukan po co? Po to żeby ukryć implementację. Zauważ że dzięki temu możesz bez problemu przepisać całą logikę działania jakiejś klasy bez konieczności zmieniania kodu który z tego korzysta.
Załóżmy że miałeś w klasie pole "średnia". W swoich kodach uzywałeś tego pola, zamiast metody getSrednia(), bo "przecież to bez różnicy". Następnie okazalo się ze nie ma sensu trzymać tej danej w osobnym polu, tylko lepiej liczyć je na bieżąco kiedy jest potrzeba.

• gdybyś używał metody getSrednia() to mógłbyś podmienić implementację i już
• skoro używałeś dostępu do pola, to musisz przepisać kody które z tego korzystały.

Ja mam lepszy przykład. Przyjmijmy, że w jakiejś metodzie przechowujemy sobie NIP, który aktualnie jest zapisywany w postaci 10 cyfrowej liczby, ale wystarczy sobie przypomnieć, że kiedyś się stosowało myślniki (tak jak w telefonach odstępy). No i teraz trzeba przyjąć od użyszkodnika tą wartość. No i sobie można teraz niezłe kuku zrobić jak się nie używa setterów bo ktoś może nam zrobić niezłą kiszkę, zwłaszcza jak przechowujemy dane jako liczbę a ktoś zechce podać string.