Programowanie Obiektowe

Hej, potrzebuje Was, aby wskoczyć na właściwą ścieżkę...
Do tej pory wszystko robiłem proceduralnie, ale ostatnio przyswoiłem sobie podstawy obiektów.
Wiecie jak jest z podstawami - tworzy się kota, który potrafi jeść, pić i chodzić...

Natomiast tworzę sobie we własnym zakresie pewną aplikację, obecnie jestem na etapie implementacji systemu odznak.
Użytkownik może dostać odznakę za np. utworzenie konta jako jeden z pierwszych, napisanie X komentarzy itd.
Chciałbym - w ramach nauki - zastosować OOP. Ale za nic nie wiem jak do tego podejść.

Pomóżcie mi proszę, wyjaśnijcie w czym OOP okaże się bardziej skuteczne od napisania kilku prostych funkcji, które będą odpowiedzialne za przyznanie odznaki użytkownikowi, pobranie wszystkich odznak użytkownika itd.

Nie proszę o gotowe rozwiązania, ale o nakierowanie.
Niestety, nie widzę związku między stworzeniem kota czy psa, a moim problemem.

Dzięki!

W przypadku prostej aplikacji nie jest wcale powiedziane, że OOP koniecznie musi być lepsze.

Programowanie obiektowe to nie jest jakiś święty Graal i cel sam w sobie, że jego użycie z automatu uszlachetnia każdy projekt ;) Ma ono również swój koszt - chociażby taki, że przeważnie wymaga większej ilości kodu (tzw. boilerplate). Nie brak ludzi krytycznie nastawionych wobec programowania obiektowego i atakujących je z rozmaitych pozycji.

Na pewno jednym z atutów jest to, że programując obiektowo izolujesz od siebie różne komponenty. To bardzo pomaga w pisaniu np. testów jednostkowych. Jeśli twój użytkownik jest obiektem "User", możesz łatwo (na potrzeby testu) sfingować fałszywego użytkownika, tworząc go - że tak powiem obrazowo - w probówce, i sprawdzić na nim działanie logiki. Oto np. użytkownik który ma 99 komentarzy, i test sprawdza, co się stanie, gdy dojdzie kolejny.

Gdyby projekt składał się wyłącznie z funkcji grzebiących w bazie danych naprawdę, zasymulowanie takiego scenariusza (i czyszczenie po nim!) byłoby bardziej kłopotliwe.

Drugim atutem jest lepsze posegregowanie kodu. Wiadomo z góry, że kodu związanego z użytkownikiem trzeba będzie szukać w jego klasie, a nie włócząc się po wszystkich możliwych plikach. Oczywiście użycie obiektów samo w sobie tego nie gwarantuje. Aby ten atut się zrealizował, trzeba przestrzegać różnych zasad, jak SRP czy prawo Demeter itd.

Zgadzam się i zawsze mówię, że uczenie dziedziczenia na bazie durnych przykładów z kaczką itp. jest głupotą, która nic początkującym nie wyjaśnia. Amatorom tego podejścia wydaje się, że jak przykład będzie infantylny, to siłą rzeczy będzie zrozumiały, a to bzdura.

Dzięki za odpowiedź.
Masz rację. I ja to wszystko doskonale rozumiem. Nie twierdzę, że akurat pochylając się nad tym zagadnieniem (system odznak użytkowników) lepiej będzie skorzystać z OOP.
Nie.
Mimo wszystko postawiłem sobie za cel, że spróbuję to wykonać właśnie w ten sposób.

Nawet nie wiem od czego zacząć.
Dla mnie to wszystko można oprzeć o utworzenie jednej klasy, która będzie zawierać kilka metod (m.in. award_badge($badge_id, $user_id), remove_badge($badge_id, $user_id), get_user_badges($user_id)...).
Czy to właściwy trop?

Moim zdaniem warto zawsze oprzeć się o programowanie obiektowe. Nie widzę sensu tego unikać.
Wprawdzie ja uczyłem się programowania obiektowego już 19 lat temu :) na studiach ale myślę, że teraz też mogę Ci polecić, jak ją gdzieś wykopiesz, Symfonię C++ Grębosza. Wiem, że to C++ ale ta książka jest tak napisana, że naprawdę trzeba by było być jełopem aby nie zrozumieć najważniejszych rzeczy z programowania obiektowego. Pamiętam, że bez problemu przeskoczyłem na obiektowe w PHP choć wtedy to dopiero wchodził PHP 4 i to obiektowe było w sumie bardzo umowne i ułomne i problematyczne. Jednak myślę, że to najlepsza książka na początek. Zwłaszcza teraz gdy mamy PHP 7. Nie jest to książka w stylu "w 24h" czy "dla opornych" ale czyta się lekko, przykłady są świetne, analogie obrazowe. Warto.

pozdro
Sławek

Pomóżcie mi proszę, wyjaśnijcie w czym OOP okaże się bardziej skuteczne od napisania kilku prostych funkcji,
które będą odpowiedzialne za przyznanie odznaki użytkownikowi, pobranie wszystkich odznak użytkownika itd.

W niczym, w zasadzie zarówno OOP jak i programowanie proceduralne można napisać dobrze, albo spieprzyć. Równie dobrze możesz na siłę pchać jakieś obiekty, a możesz zrobić to proceduralnie i nie będzie to gorsze. Pod warunkiem, że napiszesz to proceduralnie w sposób dobry (zarazem elastyczny, ale i niezbyt skomplikowany, dający się łatwo zmienić w przyszłości, ale nie wymagający zbytniej konfiguracji itp. -- można to sprowadzić do paru prostych akronimów typu SOLID czy DRY albo KISS - chociaż też nie należy brać tych akronimów jak dogmat. To są tylko wskazówki jak ładnie pisać). Więc to nie kwestia paradygmatu (OOP, proceduralny, funkcyjny itp.) a raczej ogólnej jakości kodu.

Z drugiej strony nic nie stoi na przeszkodzie, żeby to zrobić obiektowo.

Chciałbym - w ramach nauki - zastosować OOP. Ale za nic nie wiem jak do tego podejść.

Wskazówka. Jak masz rzeczownik, to często się to przekłada bezpośrednio na obiekt, jak masz czasownik to na metodę.

Użytkownik może dostać odznakę za np. utworzenie konta jako jeden z pierwszych, napisanie X komentarzy itd.

Chciałbym - w ramach nauki - zastosować OOP. Ale za nic nie wiem jak do tego podejść.

Tu już masz obiekty w zasadzie. Użytkownik to obiekt, "pisz" to metoda, "komentarz" to jakiś inny obiekt (metoda "pisz" operuje na tych obiektach-komentarzach itp.).

Oczywiście, czasem takie podejście będzie zbyt naiwne, jednak myślę, że to dobry punkt startowy. W końcu już de facto masz (w wyobraźni) jakieś obiekty typu użytkownik, konto, komentarz. Nie zawsze się to można przełożyć 1:1 na kod (czasem potrzeba w kodzie dodatkowych abstrakcji, albo odwrotnie - jakichś uproszczeń), jednak obiektówka miała chyba w założeniu odzwierciedlać rzeczywistość (stąd te pszczółki i kotki w podręcznikach).

Druga wskazówka - warto rysować na papierze kwadraty(reprezentujące poszczególne obiekty) i łączyć je strzałkami. To pomaga zwizualizować sobie co właściwie te obiekty robią, w jaki sposób są połączone.