[t.....l]

Mirki, mam pytanie odnośnie programowania obiektowego w #php. Jestem, jak już kiedyś wspominałem, początkujący w temacie i nie wiem, jakie praktyki są dobre, a jakie złe, bądź też na ile swobodnie można podejść do pewnych kwestii.

Problem jest następujący: chcę sobie dla wprawki napisać klasę obsługującą zarządzanie użytkownikami i mam dylemat, bo nie wiem, jak to do końca zrobić. Dla uproszczenia zakładam, że user będzie miał login i hasło, bez zbędnych parametrów. Klasa natomiast powinna obsługiwać dodawanie, usuwanie, modyfikowanie konta użytkownika, sprawdzanie, czy użytkownik istnieje i pobierać dane użytkownika.

Wyobrażam to sobie mniej więcej tak: http://pastebin.com/f4iwAzjg

Zastanawiam się, czy dobrze kombinuję - metody do tworzenia, aktualizacji i usuwania usera robię jako statyczne, przekazując do nich obiekt, na którym chcę dokonać zmiany, ale pobieranie i ustawianie loginu i hasła wykonuję bezpośrednio na obiekcie.

Oczywiście to tylko uproszczona forma, ale pytanie - czy tak właśnie powinno to mniej więcej wyglądać? Czy może metody operujące na koncie powinny być wywoływane przez instancję obiektu? A może wydelegowane do innej klasy?

[evan_wykop]

@tomash-pl: zle. Dao i encja user

[banditpanda]

http://pl.phptherightway.com/, http://pl.wikipedia.org/wiki/Solid_%28programowanie_obiektowe%29

Ogólnie, dobrze kombinujesz z tym, że teraz Twoja klasa użytkownika łamię zasadę jednej odpowiedzialności, czy na pewno użytkownik powinien wiedzieć jak dodać rekord do bazy danych?
Wydziel część tego kodu do klasy np UserRepository i tam zapisuj dane w bazie. Najlepiej gdybyś zaczepił się o jakiś sprawdzony framework np Symfony2 który pokaże Ci pewne rozwiązania.

[t.....l]

@evan_wykop: czyli tak, jak napisałem na koniec, wydelegowanie obsługi zapisu, usuwania i modyfikacji do innej klasy (na przykład UserDAO?) i przekazywanie jako argumentu do metod instancji obiektu User?

@banditpanda: no właśnie chcę usiąść do Symfony 2, ale przedtem chciałbym dla wprawki napisać coś sam, żeby zrozumieć ideę i zasady OOP, czyli dlaczego coś ma być statyczne, dlaczego chronione, kiedy interfejs, a kiedy trait. Niestety, zatrzymałem się na proceduralnym

[banditpanda]

http://fabien.potencier.org/article/50/create-your-own-framework-on-top-of-the-symfony2-components-part-1

przeklikaj sobie ten artykuł, powinien przybliżyć Cię do koncepcji jakie dziś możesz spotkać w świecie PHP.

[t.....l]

@banditpanda: dziękuję :) na pewno poczytam, mam nadzieję, ze coś zrozumiem :D

[ghost1511]

@tomash-pl: Do logowania powinieneś napisać klasę która będzie odpowiadała za autentykację. I to tam powinieneś umieścić logowanie, i zwracanie ewentualnego obiektu użytkownika.

[t.....l]

@ghost1511: no ok, ale tu nie było logowania, tylko sama klasa User, która w założeniu ma jedynie operować na danych. Przy obecnym stanie mojej wiedzy, zrobiłbym klasę Authenticate ze statyczną metodą ::login($login, $password) i przy powodzeniu zwracającą obiekt klasy User. :)

[banditpanda]

@tomash-pl: ogólnie, na początek odczep się od funkcji statycznych :)

[t.....l]

@banditpanda: o, a mógłbyś nieco rozwinąć tę myśl? :)

[Jaslanin]

@tomash-pl: google: static is evil

[banditpanda]

są różne szkoły, ale wg. mnie funkcje statyczne powinny być bezstanowe i całkowicie przewidywalne, np Calculator::add(1,2) wynik takiego działania możemy przewidzieć i nawet jeśli wywołasz go 1000 razy wynik się nie zmieni. Metody statyczne są dostępne globalnie, co jest złą praktyką powoduje zaciemnienie kodu.

[t.....l]

@Jaslanin: @banditpanda: no dobra, ale jak to się ma do http://pl.phptherightway.com/pages/Design-Patterns.html#factory ?

[ghost1511]

Powinieneś utworzyć klasę Authenticate w konstruktorze przekazać połączenie do bazy danych. A następnie wywoływać funkcję obiektu login($user, $password).

Jak powiedział @banditpanda unikaj funkcji statycznych ;)

[t.....l]

@ghost1511: no dobra. I ta funkcja login powinna zwrócić obiekt User, na którym miałbym manipulować, tak?

[ghost1511]

@tomash-pl: Tak. Zakładając, że przekazałeś połączenie do bazy przez konstruktor - wykonujesz zapytanie do bazy które zwraca Ci dane użytkownika, które przekazujesz do konstruktora klasy User. Oczywiście mówimy o tym optymistycznym przypadku, kiedy logowanie jest poprawne.

[ghost1511]

@tomash-pl: Wracając, do tematu funkcji statycznych - użycie ich musi być uzasadnione. Mówi Ci to człowiek, który ten błąd popełnił w przeszłości i płaci za to do dziś :P lepiej uczyć się na czyichś błędach ;)

[t.....l]

@ghost1511: no to jeszcze rozumiem, ale weźmy teraz sytuację, kiedy jestem adminem i chcę pobrać listę userów i zmodyfikować albo usunąć jednego z nich - w jaki sposób pobrać tę listę? Nielogiczne wydaje mi się tworzenie klasy "UsersList" ani tworzenie obiektu User majacego metodę getUsersList()... Czy tu powinna być użyta metoda statyczna User::usersList() czy tak, jak wspominał @evan_wykop obiekt $UserDAO->getUsersList()?

[t.....l]

Mówi Ci to człowiek, który ten błąd popełnił w przeszłości i płaci za to do dziś

@ghost1511: a opowiesz, co się dokładnie stało?

[banditpanda]

@tomash-pl: w tej całej układance brakuje Ci chyba jeszcze kontrolera.

eg. user/index

$userRepository->all();