Czytając książke o OOP, nie rozumiem metod ustaw i pobierz...

Po co takie metody tworzyć? Nie można działać bezpośrednio na danych składowych?

np.

[PHP] pobierz, plaintext 
////////////////////////////////////////////////////////////////////
   function setInactiveSpanName($name){
    $this->inactivespanname = $name;
    //wywołuje funkcję zmieniającą nazwę przestrzni
    $this->createInactiveSpans();  
  }
////////////////////////////////////////////////////////////////////
   function getInactiveSpanName(){
    return $this->inactivespanname;
  }
////////////////////////////////////////////////////////////////////
   function setPageDisplayDivName($name){
    $this->pagedisplaydivname = $name;    
  }
////////////////////////////////////////////////////////////////////
   function getPageDisplayDivName(){
    return $this->pagedisplaydivname;
  }
////////////////////////////////////////////////////////////////////
   function setDivWrapperName($name){
    $this->divwrappername = $name;    
  }
////////////////////////////////////////////////////////////////////
   function getDivWrapperName(){
    return $this->divwrappername;
  }
////////////////////////////////////////////////////////////////////
   function setFirstParamName($name){
    $this->firstparamname = $name;    
  }
////////////////////////////////////////////////////////////////////
   function getFirstParamName(){
    return $this->firstparamname;
  }
////////////////////////////////////////////////////////////////////
[PHP] pobierz, plaintext 

W twoim przypadku nie ma sensu tworzyć takich metod.
Tworzy się je wtedy jeżeli musisz skontrolować typ wartośći jaką podaje użytkownik do podanej właściwości. Np użytkownik podal liste elementów w formie stringa a nie tablicy i dzięki "setter"om takie coś sprawdzisz i skontrolujesz. Podobnie jest z innymi typami.

[PHP] pobierz, plaintext 
 
// wartosc musi byc instancja View
public function setView(View $view)
{
   $this->_view = $view;
 
}
 
// atrybut musi byc tablica
public function setElement(array $elements)
{
// dodatkowa walidacja
  $this->_elements = $elements;
}
 
// konwertujemy na int
public function setOrder($order)
{
   $this->_order = (int)$order;
}
[PHP] pobierz, plaintext 

Gettery mogą mieć też parę innych przydatnych właściwości jak kontrola co i kiedy zwracać w wynikach.
Poniżej jest kontrola wyświetlania elementu.

[PHP] pobierz, plaintext 
 
public function blockDisplay($to)
{
  $this->_displayLock = (bool)$to;
}
 
public function display()
{
   if($this->_displayLock) return '';
   else return $this->_display();
}
 
[PHP] pobierz, plaintext 

Np.

private $inactivespanname = "inactive";

żeby zmienić danę składową piszemy settera? Po co wtedy getter?

[PHP] pobierz, plaintext 
public function setInactiveSpanName($name){
    $this->inactivespanname = $name;
    //wywołuje funkcję zmieniającą nazwę przestrzni
    $this->createInactiveSpans();  
  }
////////////////////////////////////////////////////////////////////
  public function getInactiveSpanName(){
    return $this->inactivespanname;
 
////////////////////////////////////////////////////////////////////
[PHP] pobierz, plaintext 

Po to zeby wartosc wyswietlic/pobrac bez niego takie cos:

[PHP] pobierz, plaintext 
$obiekt -> polePrivate;
[PHP] pobierz, plaintext 

Zwroci blad tak samo z protected.

W celu zachowania Enkapsulacji/Hermetyzacji. Niektórzy uważają nawet ( w tym ja ) że wszystkie zmienne klas powinno się opatrywać modyfikatorami private lub protected <edit>( ewentualnie protected )</edit>. Innymi słowy nie powinno się pozwalać na dostęp do zmiennych składowych klasy z poza niej samej.

No właśnie bo wookieb mówi o danych wprowadzonych przez usera. Jeżeli dane składowe sa private to po co setter, getter?

Po to, żeby mieć do nich dostęp (jako, że nie są to pola publicznie nie można ich sobie ot tak po prostu bezpośrednio ustawić, no chyba że magiczny setter/getter, ale to inna bajka), jeśli zachodzi taka potrzeba i żeby ten dostęp w jakiś sposób móc kontrolować/filtrować etc. Standardowo klasy nie pozwalają na dostęp do składowych o dostępie innym niż publiczny, toteż należy utworzyć getter i setter. Tylko o to chodzi w tym przypadku.

Klasy w wielu obiektowych lub obiektowo orientowanych językach mają 3 tryby dostępu: publiczny (public), prywatny (private) i chroniony (protected). Różnica między nimi jest taka, że do publicznego możesz się odwoływać bezpośrednio
$obiekt_klasy -> atrybut
a więc zapis i odczyt są jawne. Wystarczy znać strukturę danych.

Prywatne są zabezpieczone i nie odczytasz ich ani nie zapiszesz nic do nich bez metod, które sama klasa Ci udostępnia. Odwołanie jak do publicznego spowoduje błąd. Jest to zabronione. Dlatego właśnie musisz napisać metodę, która pozwala go ustawić lub odczytać, a więc pozwala zrobić tak:
$obiekt_klasy -> odczytaj_pole_X();

Dostęp chroniony jest w samej klasie widoczny jako prywatny, ale klasa która po niej dziedziczy zamienia go w prywatny w swojej klasie (to zależy od języka programowania, gdyż w pewnych może on stać się publicznym ). Normalnie bowiem klasa nie dziedziczy pól klasy rodzica, a więc można powiedzieć, że dziecko wszystkie pola rodzica "zapomina", poza oczywiście tymi będącymi protected. Jeśli więc masz klasę A, zaś w niej pola public, private i protected, to po utworzeniu z niej klasy potomnej B znajdziesz wewnątrz tylko te, które były protected, ale będą one już teraz private (lub public w określonych językach).

Jak więc widzisz definicja dostępu sprawia, że pola zachowują się różnie. Inaczej do nich odwołujesz, inaczej zachowują w przypadku tworzenia klasy pochodnej.

Ale to są podstawy obiektówki, więc radzę Ci dobrze się przyłożyć do nich bo im głębiej w las tym więcej drzew o jakie można się rozbić.

Thek... ale namieszałeś. Pyta o kompletne podstawy na forum PHP, to tłumacz tylko na przykładzie PHP, z którym będzie pracować.

O modyfikatorach dostępu pisać nie będę bo IIRC jest to kompletnie opisane w manualu.
Po co stosować gettery/settery?

1) Wspomniana hermetyzacja
2) Kontrola danych
3) Bardziej przyszłościowe rozwiązanie - zawsze można w przyszłości coś dodać, zachowując niezmienny zewnętrzny interface.

Ja mu zrobiłem przyspieszony kurs z modyfikatorów dostępu Można to maksymalnie rozwijać na kilka stron choćby, ale wolałem mu to przekazać "w pigułce". Jak na mnie i tak krótki post, a myślę, że opisałem to bardzo przystępnie. Raczej trudno to będzie opisać bardziej łopatologicznie, bez rozwlekania i sypania przykładami.

No to zapomniałeś opisać o takich modyfikatorach jak chociażby pakietowy (z Javy). W C# istnieje chyba jeszcze pakietowy chroniony (ale nawet nie jestem pewien - nie znam tej tech., a przeszukiwać MSDN mi się nie chce :]).

Wiesz... Można by jeszcze dodać od biedy static Jest to w końcu także pewna forma dostępowa zmiennej o zasięgu ograniczonego nie tyle do obiektu klasy co wszystkich obiektów tejże klasy.

Modyfikatory dostępu/specyfikatory w Javie, które mnie najbardziej zaintrygowały to: native oraz synchronized

Native: gdy mamy jakąś metodę napisaną np. w C/C++ - więcej na: http://mindprod.com/jgloss/native.html
Synchronized: blokuje metodę/blok kodu dla innych wątków - więcej na: http://mindprod.com/jgloss/synchronized.html