Przeglądałem kilkadziesiąt klas i zastanawiam się po co ludzie piszą na siłę dodatkowe metody np:

[PHP] pobierz, plaintext 
class Stefan {
 
   public $ubranie;
   public $buty;
   public $czapka;
 
   public function setUbranie($jakie) {
      $this->ubranie = $jakie;
   }
 
   public function getUbranie() {
      return $this->ubranie;
   }
 
}
 
[PHP] pobierz, plaintext 

i później wywołanie:

[PHP] pobierz, plaintext 
$o->setUbranie('jensy');
echo $o->getUbranie();
[PHP] pobierz, plaintext 

zamiast:

[PHP] pobierz, plaintext 
$o->ubranie='dress';
echo $o->ubranie;
[PHP] pobierz, plaintext 

mniej niepotrzebnego kodu a nadal jest bardzo czytelny
edit: no i z klasy wypadają dwie niepotrzebne metody

To się nazywa Getter i Setter
Do tak trywialnego problemu oczywiście że bez sensu.

Ale już przy bardziej złożonych problemach może być bardziej użyteczne, np. pobierając wartości zawsze robimy htmlspecialchars, dzięki temu zmieniamy w jednym miejscu a nie 1000 przy zapisywaniu lub odczytywaniu.

jak najbardziej w takich przypadkach(tych co ty podałeś) widzę sens, ale zauważyłem że ludzie nadużywają do takich prostych rzeczy jak ustawienie zmiennej masy metod, dla mnie to brak optymalizacji.

Zboczenie takie Jeśli nie ma konkretnej przesłanki aby używać ww. metod, to nie ma sensu stosowania.
W internecie jest wiele archeologii i bzdur które potem ludzie dublują.

Dzięki, bo już myślałem że ze mną coś jest nie tak

jak napiszesz większą hierarchę klas wtedy zrozumiesz:D
akurat w tym przykładzie nie ma to sensu ale już w tym poniższym jak najbardziej

[PHP] pobierz, plaintext 
class Stefan {
 
   protected $ubranie;
   protected $buty;
   protected $czapka;
 
   public function setUbranie($jakie) {
      $this->ubranie = $jakie;
   }
 
   public function getUbranie() {
      return $this->ubranie;
   }
 
}
[PHP] pobierz, plaintext 

a dlaczego bo nie zawsze chcemy aby zmienne składowe klasy były dostępne zewnątrz, chodzi tu głównie o kontrolę aplikacji.

[PHP] pobierz, plaintext 
class konto {
 
public$kasa= 0;
 
}
 
$konto = new $konto;
$konto->kasa = 1200;
 
echo $konto->kasa;
 
[PHP] pobierz, plaintext 

Teraz wyobraź sobie młodego programistę który przez przypadek zamiast porównać $konto->kasa == 100 daje $konto->kasa = 100
Ile będziesz miał na koncie ?

sprawdz co sie kryje pod: Hermetyzacja (enkapsulacja, ang. encapsulation)

Hermetyzacja zapewnia że jak za kilka miesięcy pojawi się potrzeba dodania ficzeru to wystarczy zmodyfikować getFoo zamiast połowę kodu itd

ma to jeszcze jedna zaletę, "zawsze jest tak samo".

Kiedyś zacząłem się "uczyć biblioteki" wxwidgets(to taka biblioteka do c++). Po kilku godzinach miałem już dosyć, w tej bibliotece część opcji jest(była ?) przekazywanych jako parametry, a cześć przez getery i setery. I weź tu teraz człowieku zastanawiaj się co chwilę i sprawdzaj w dokumentacji czy może szerokość to mam przekazać jako setWidth czy może width=

Powiem Tobie przyjacielu że mnie przekonałeś. To jest jeden konkretny powód dla którego warto dokładać kod, tracąc na optymalizacji.

1. Nie przejmuj się mikroskopijnymi stratami wydajności - nie są warte uwagi tutaj w przeciwieństwie do dobrej jakości samego kodu.
2. Settery umożliwiają jakąkolwiek kontrolę nad tym co się dzieje i co jest przekazywane w kodzie. Tak, są nieco monotonne w pisaniu, ale pierwsze lepsze IDE załatwi to za Ciebie.
3. Kod staje się zdecydowanie mniej wrażliwy na zmiany. Wewnętrzny stan obiektu nie jest udostępniony bezpośrednio zewnętrznemu "użytkownikowi".

No ale jeśli mamy gettery i settery, to z jednak definicji wewnętrzny stan obiektu jest udostępniany zewnętrznemu użytkownikowi (tyle, że pośrednio, jedyna różnica), i użytkownik może odczytać albo zmienić stan obiektu w dowolnym momencie. I to niebezpiecznie łamie zasadę enkapsulacji.

Dlatego trzeba to robić z rozsądkiem, są sytuacje gdzie gettery i settery są użyteczne, ale stosowanie ich na oślep bo komuś się wydaje, że na tym polega programowanie obiektowe (co jest kompletną bzdurą).

Zamiast setterów/getterów setUbranie (pomijając już, że pisanie zmiennych pół po polsku, pół po angielsku nie ma sensu), można np.:

- zlikwidować potrzebę odwołania się do zmiennych obiektu. Np. załózmy, że mamy konto bankowe. Wtedy jeśli chcemy komuś odjąć kasę z konta, wtedy zamiast pisać

[PHP] pobierz, plaintext 
 $account->setMoney($account->getMoney() - 100)
[PHP] pobierz, plaintext 

co jest dość brzydkie (i również podatne na pomyłki nie bardziej niż twój przykład, @memory, wystarczy, że komuś się plus z minusem pomyli), możemy zrobić metodę charge:

[PHP] pobierz, plaintext 
 $account->charge(100)
[PHP] pobierz, plaintext 

wtedy obiekt sam będzie wiedział, co zrobić z tymi pieniędzmi. Jednocześnie zlikwidujemy potrzebę odwoływania się do wewnętrznego stanu obiektu.

- można jeszcze zlikwidować w ogóle stan obiektu i pozwolić na ustawianie ubrania tylko przy inicjalizacji obiektu (a później dany obiekt byłby po prostu niezmienialny). Wtedy jeśli byśmy chcieli zmienić ubranie to po prostu tworzylibyśmy nowy obiekt klasy Stefan, który by miał skopiowane z poprzedniego właściwości, oprócz ubrania, które byśmy ustawili inne.

Setterami możesz też wymuszać konkretny typ danych

[PHP] pobierz, plaintext 
public function setDate(DateTime $timestamp)
[PHP] pobierz, plaintext 

Od 7 również typy podstawowe oraz zwracany typ danych. Świetnie sprawdzają się również z hydratorami (automatyczne transormacje między np danymi z bazy a encjami w aplikacji).

Jak najbardziej tak - wszystko trzeba stosować "właściwie".