Witam,

czytam o OOP bo mam zamiar to w koncu pojąć ...

do rzeczy mam kod

[PHP] pobierz, plaintext 
<?php
class zwierze {
 
  private function jedz(){
    echo 'Gryz gryz';
  }
 
  public function zrobCokolwiek(){
    $this->jedz();
  }
}
 
$zwierze = new zwierze;
$zwierze->zrobCokolwiek();
 
?>
[PHP] pobierz, plaintext 

po co pisać metode private skoro i tak w public sie do nie odniosę przecież to bez sensu (no albo jeszcze mało wiem )
skoro można napisać od razu

[PHP] pobierz, plaintext 
 <?php
 class zwierze {
 
   public function zrobCokolwiek(){
    echo 'Gryz gryz';
   }
 }
 
 $zwierze = new zwierze;
 $zwierze->zrobCokolwiek();
 
 ?>
 
[PHP] pobierz, plaintext 

Niech mi to ktoś w końcu racjonalne wytłumaczy

No w tym przypadku to akurat bez sensu jest rozbijać to na dwie metody (w ogóle bez sensu jest tutaj robić obiekt).
Google: OOP hermetyzacja

Ja również tak powoli, powolutku, bardzo powolutku przechodzę na OOP i również mam dylematy: czy tu będzie dobrze, czy może jednak nie?
Najlepszy przykład pokazujący zalety OOP to chyba wałkowany setki razy interfejs + implementujące go sterowniki do bazy danych.
Nie zawsze jest dostęp do PDO (o ile już się o nim oczywiście dowiemy), zaś rozdzielanie silników w proceduralnym przez if / else byłoby chorym rozwiązaniem.

Dla mnie obecnie dylematem są sprawy typu: chcę zrobić sobie stronę z dodawaniem artykułów i wpisów. Czy robić klasę dla artykułów (metody typu: addArticle, deleteArticle, searchArticle), czy może rozwiązać to w inny sposób? Jak do tego dorzucam MVC to już niezły mętlik się robi. No ale powolutku idę do przodu

No ja mam dokładnie to samo tylko wiesz kurcze pisząc tu myślałem że otrzymam odpowiedź z + - a to tylko forma bardzo krótkiej odpowiedzi ;D oczywiście mogę luknąć do google i znaleźć setki artów no ale lepiej uzyskać odpowiedzi że tak powiem na konkretny problem w tej chwili no ale jak to mówią "Życie "

to stosunkowo proste, tworząc bibliotekę przy użyciu tradycyjnego programowania strukturalnego, nie ma sposobu (przynajmniej w PHP) aby ukryć przed użytkownikiem końcowym te funkcje, których naszym zdaniem nie powinien bezpośrednio wywoływać. W OOP możemy to zrobić bardzo łatwo - metody prywatne nie mogą być wywołane poza obiektem. Można więc dostarczyć użytkownikowi "czarne pudełko" - użytkownik końcowy może używać jedynie metod oznaczonych jako publiczne, które zwykle służą za interfejsy, podczas gdy cała implementacja jest "ukryta" za pomocą metod prywatnych. Jeśli za jakiś czas wypuścimy nową wersję naszej biblioteki, możemy dowolnie pozmieniać wszystkie metody prywatne, mając 100% pewności, że nie stracimy kompatybilności z poprzednią wersją, o ile metody publiczne pozostaną takie same.

JohnnyB NO znacząco mi to już rozjaśniłeś ... i Tak jest najlepiej (twoja wypowiedz)