Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [MySQL][PHP] Przebudowa klas/struktura klas
Forum PHP.pl > Forum > Przedszkole
Matkas
Witam,
jako iż to mój pierwszy post na tym forum to wypadałoby się przedstawić.
Jestem 17nastolatkiem , który dopiero co raczkuje w php, pochodzącym z bardzo znanego miasta Bogatynia(7.08.2010), a na imię mam Mateusz! smile.gif

A przechodząc do mojego problemu, to dawniej napisałem system logowania(o ile można to tak nazwać), ale teraz jak jestem starszy i mądrzejszy, to chciałbym Go przebudować, i zaczać bardziej doceniać OOP. Oczywiście wiem, że wszystko jest tu źle, dlattego chciałbym napisać wszystko od początku. Próbuje sobie uzmysłowić ile klas potrzebuje do logowania, i chodzenia po podstronach, w których wymagane jest zalogowanie.
Myślałem nad takimi:
class user_auth - Autoryzacja użytkownika, znajdują sie w niej funkcje potrzebne do zalogowania, informacje o użytkowniku(user_id itp.)
class session - Klasa zarządzająca sesjami oparta na bazie
class account_managment - Klasa do zarządzania kontem,zmiana haseł,informacji o profilu itd.

Problem mój polega na tym, że nie wiem jak te wszystkie 3 klasy połączyć, i w jaki sposób je dobrze napisać.
Próbowałem w mojej aktualnej klasie wprowadzić atrybuty, takie jak user_id,user_login,user_level. Lecz odwołując się do nich w innych plikach, nie uzyskuje żadnego rezultatu. Wygląda to mniejwięcej tak:

Nagłówek account.php
  1. require_once ("mainfile.php");

Nagłówek mainfile.php
  1. require_once('functions.php');
  2. require_once('config/config.php');
  3. require_once('class/class_database.php');
  4. require_once('class/class_account.php');
  5. $class_database = new class_database;
  6. $class_account = new class_account;


Lecz w obu tych plikach nie jestem w stanie odwołać się do $class_account->user_id;
W jaki sposób zoptymalizować klasy?


Poniżej skrypt logowania o którym wcześniej wspominałem.
  1. function login($login_in_login_form,$password_in_login_form)
  2. {
  3. $login_exist = $this->check_login_exist($login_in_login_form);
  4. //Sprawdza czy login wpisany w formularzu istnieje
  5. if($login_exist==TRUE)
  6. //Jesli istnieje to ->
  7. {
  8. $password_match = $this->confirm_password_in_login($login_in_login_form,$password_in_login_form);
  9. //Sprawdza czy haslo pasuje do loginu
  10. if($password_match == TRUE)
  11. //Jesli pasuje to ->
  12. {
  13. $if_activated = $this->check_account_activated($login_in_login_form);
  14. //Sprawdza czy konto jest aktywowane
  15. if($if_activated == TRUE)
  16. //Jesli konto aktywowane to->
  17. {
  18. $this->setsessions( $login_in_login_form);
  19. // Ustawia sesje
  20. $sucesfull = "Login sucesfull! In(".RELOAD_TIME." seconds) you'll be redirected.";
  21. $to_display .= display_good(redirect($sucesfull));
  22. //Funkcja `display_good` wyswietla tekst w odpowiednim 'pojemniku'
  23. //Funkcja `redirect` przekierowuje na daną strone(tu 'account'), i wyswietla komunikat.
  24.  
  25. }//Jesli konto nie aktywowane to
  26. else
  27. {
  28. $notactivated = "Account not activated";
  29. $to_display .= display_alert($notactivated));
  30. //Funkcje jak wyzej
  31. }
  32.  
  33. }//Jesli haslo nie pasuje to wyswietl na ekranie
  34. else
  35. {
  36. $to_display .= display_wrong("Bad password.");
  37. }
  38. }//Jesli login nie istnieje
  39. else
  40. {
  41. $to_display .= display_wrong("This user does not exist.");
  42. }
  43. return $to_display;//zwroc wynik
  44. }


Pozdrawiam, Mateusz
osl
Poczytaj sobie o MVC.
W skrócie - najlepiej zrobić z usera model "User", gdzie przechowujesz sobie dane z bazy. Dodatkowo, możesz w nim przechowywać dane z sesji - te które dotyczą usera.
Do tego kontroler do logowania, wylogowania, zmiany danych itp.
Po zalogowaniu ustawiasz odpowiednie flagi w modelu (a konkretnie w danych zapisywanych w sesji).
Crozin
Cytat
Poczytaj sobie o MVC.
Czy MVC to już odpowiedź na każde pytanie jakkolwiek związane z OOP? Po pierwsze co ono ma tutaj w ogóle do rzeczy? Pytanie dotyczy mechanizmu autoryzacji oraz podstawowych "elementów" OOP takich jak współpraca obiektów czy projektowanie klas.
Cytat
Dodatkowo, możesz w nim przechowywać dane z sesji - te które dotyczą usera.
Nie powinien na jeden obiekt zrzucać odpowiedzialności za kompletnie różne rzeczy.

Co do tematu...
1. PHP ma słabo rozpowszechnione konwencje dot. nazewnictwa, stylu formatowania kodu, itp. Ma jeszcze problemy z konfliktami tych konwencji z ery przed i po wprowadzaniu OOP do języka. Nie mniej jednak ma je, więc trzymaj się nich. Nazewnictwo klas: http://groups.google.com/group/php-standar...-final-proposal Nazewnictwo zmiennych: camelCase
2. Używaj mechanizmów automatycznego ładowania klas (ang. autoloading)
3. Unikaj wielokrotnego zagnieżdżania bloków. Pamiętaj, że większość konstrukcji typu:
  1. if (...) {
  2. if (...) {
  3. if (...) {
  4. if (...) {
  5. ...
  6. } else {
  7. return ...;
  8. }
  9. } else {
  10. return ...;
  11. }
  12. } else {
  13. return ...;
  14. }
  15. } else {
  16. return ...;
  17. }
Da się zastąpić przez dużo czytelniejsze:
  1. if (!...) {
  2. return ...;
  3. }
  4.  
  5. if (!...) {
  6. return ...;
  7. }
  8.  
  9. if (!...) {
  10. return ...;
  11. }
  12.  
  13. if (!...) {
  14. return ...;
  15. }
  16.  
  17. ...

4. Jak chcesz pisać obiektowo to pisz obiektowo. Nie twórz funkcji (nie unikniesz korzystania z natywnych funkcji ponieważ PHP bibliotekę standardową ma właściwie w pełni strukturalną), nie korzystaj z globalnej przestrzeni nazw.
5. Od obsługi błędów są wyjątki, a nie jakieś nie do końca wiadomo co...
6. Jeden obiekt - jedno zadanie - tej regułki wyucz się na pamięć. Czyli z obiektu odpowiedzialnego za autoryzację użytkownika wylatują śmieci związane z wyświetlaniem komunikatów użytkownikowi.

Cytat
Próbuje sobie uzmysłowić ile klas potrzebuje do logowania, i chodzenia po podstronach, w których wymagane jest zalogowanie.
Z OOP w PHP wiąże się jedna potworna wada. Jeżeli chcesz szkielet aplikacji napisać obiektowo musisz właściwie wszystko napisać samemu.

Co potrzebujesz do najprostszej strony gdzie da się jedynie zalogować i poruszać po podstronach?
- Obiektu reprezentującego żądanie (Request) i odpowiedź (Response). Ten pierwszy będzie zawierać informacje o parametrach żądania, czyli m.in. dane ze zmiennych superglobalnych GET/POST/SERVER/COOKIE/FILES. Ten ostatni to przede wszystkim wygenerowana treść strony i nagłówki do zwrócenia użytkownikowi.
- Obsługa sesji, czyli obiekt Session udostępniający dane z sesji oraz pomocniczy obiekt pozwalający na zapisanie tych danych w bazie (implementujący odpowiedni interfejs)
- Obsługa bazy danych - tu akurat jest dobrze, bo PHP ma wbudowane PDO
- Kilka obiektów do reprezentacji i zarządzania danymi biznesowymi - w tym przypadku chodzi o Użytkownika. Potrzebujesz obiekt, który będzie go reprezentować, kolejny który będzie w stanie go zapisywać (np. w bazie danych), kolejny który będzie pozwalać przeszukiwać ową bazę i zwracać użytkowników. Tutaj właściwie od razu możesz wykorzystać jakiś gotowy ORM np. Doctrine2.
Matkas
Cytat
Co do tematu...
1. PHP ma słabo rozpowszechnione konwencje dot. nazewnictwa, stylu formatowania kodu, itp. Ma jeszcze problemy z konfliktami tych konwencji z ery przed i po wprowadzaniu OOP do języka. Nie mniej jednak ma je, więc trzymaj się nich. Nazewnictwo klas: http://groups.google.com/group/php-standar...-final-proposal Nazewnictwo zmiennych: camelCase
2. Używaj mechanizmów automatycznego ładowania klas (ang. autoloading).

Przeczytane, zrozumiane i zapamiętane! Dzięki

Załóżmy, że mamy coś takiego:
  1. if (!$activated) {
  2. $this->Error
  3. return 0;
  4. }
  5.  
  6. if (!$password_match) {
  7. return 0;
  8. }
  9.  
  10. if (!$login_exist) {
  11.  
  12. return 0;
  13. }
  14.  
  15. if (!$this->error) {
  16. return 1;
  17. }
  18.  
  19. ...

To jak później się odwołać, do klasy wyświetlającej użytkownikowi 'błędy' logowania(konto nie zaaktywowane itp.)?

Cytat
Co potrzebujesz do najprostszej strony gdzie da się jedynie zalogować i poruszać po podstronach?
- Obiektu reprezentującego żądanie (Request) i odpowiedź (Response). Ten pierwszy będzie zawierać informacje o parametrach żądania, czyli m.in. dane ze zmiennych superglobalnych GET/POST/SERVER/COOKIE/FILES. Ten ostatni to przede wszystkim wygenerowana treść strony i nagłówki do zwrócenia użytkownikowi.
- Kilka obiektów do reprezentacji i zarządzania danymi biznesowymi - w tym przypadku chodzi o Użytkownika. Potrzebujesz obiekt, który będzie go reprezentować, kolejny który będzie w stanie go zapisywać (np. w bazie danych), kolejny który będzie pozwalać przeszukiwać ową bazę i zwracać użytkowników. Tutaj właściwie od razu możesz wykorzystać jakiś gotowy ORM np. Doctrine2.


Rozumiem, że mam takie klasy:

  1. class ClassRequest
  2. {
  3. /*Są tu funkcje odbierające zmienne superglobalne
  4.  
  5.   Tylko, nie mam pojęcia w jakim celu mam wykorzystać tą klase. Filtracja przesyłanych danych?
  6.  
  7.   */
  8.  
  9. }
  10.  
  11. class ClassResponse
  12. {
  13. // Funkcje ,które wyświetlają użytkownikowi komunikaty(np. złe hasło/login, brak aktywacji konta).
  14. }
  15.  
  16. class ClassSession
  17. {
  18. /* Funkcje, które wykonują takie czynności jak:
  19.   -Sprawdzenie kim jest osoba odwiedzająca serwis(bot, człowiek)
  20.   -Tworzenie odpowiedniej sesji dla bota/człowieka
  21.   -Aktualizowanie sesji
  22.   -Usuwanie sesji
  23.   -Sprawdzanie czy sesja istnieje
  24.   */
  25. }
  26.  
  27. class ClassAuth
  28. {
  29. // Klasa odpowiedzialna za zalogowanie użytkownika, sprawdzenie czy istnieje. (Pobiera informacje z klasy ClassRequest?)
  30. }
  31.  



Wielkie dzięki za pomoc!

Pozdrawiam, Mateusz.
Crozin
1. Przecież napisałem, że od błędów są wyjątki, a nie zwracanie 0/1.
2.
Cytat
To jak później się odwołać, do klasy wyświetlającej użytkownikowi 'błędy' logowania(konto nie zaaktywowane itp.)?
Tutaj wchodzisz w temat obsługi formularzy, czyli zagadnienia dosyć skomplikowanego - w tym celu powstają całe "subframeworki" w popularnych projektach.
3.
Cytat
Tylko, nie mam pojęcia w jakim celu mam wykorzystać tą klase. Filtracja przesyłanych danych?
Pisząc o obiekcie Request miałem na myśli obiekt reprezentujący żądanie HTTP. A chyba wiesz jakie dane zawiera takie żądanie?
4.
Cytat
// Funkcje ,które wyświetlają użytkownikowi komunikaty(np. złe hasło/login, brak aktywacji konta).
Pisząc o obiekcie Response miałem na myśli obiekt reprezentujący odpowiedź HTTP, czyli zestaw nagłówków (jak np. ciasteczka, prośba o przekierowanie, informacja o zarządzaniu pamięcią tymczasową) i treść odpowiedzi (którą generuje skrypt).
5.
Cytat
Funkcje, które wykonują takie czynności jak:
Za każdym razem, gdy do opisu obiektu potrzebujesz używać spójnika "i" oznacza to, że najprawdopodobniej powinieneś podzielić go na mniejsze obiekty odpowiedzialne za poszczególne zadania. Oczywiście "dodaj/usuń/zmień" itp. traktuje się jako jedno.
Matkas
Cytat
1. Przecież napisałem, że od błędów są wyjątki, a nie zwracanie 0/1.


Czyli mój kod wtedy wyglądałby w ten sposób:
  1. if (!$activated) {
  2. $this->Error
  3. throw new Exception($user['login'][1]);
  4. // Obsługując wyjątki, przejmowałbym parametry tablicy, i odpowiednio interpretował numer 'błędu'
  5. }
  6.  
  7. if (!$password_match) {
  8. throw new Exception($user['login'][2]);
  9. }
  10.  
  11. if (!$login_exist) {
  12.  
  13. throw new Exception($user['login'][3]);
  14. }
  15.  
  16. if (!$this->error) {
  17. return 1;
  18. }
  19.  

Cytat
3. Pisząc o obiekcie Request miałem na myśli obiekt reprezentujący żądanie HTTP. A chyba wiesz jakie dane zawiera takie żądanie?

Zawiera informacje o Nas samych jeśli się nie myle?

Cytat
5. Za każdym razem, gdy do opisu obiektu potrzebujesz używać spójnika "i" oznacza to, że najprawdopodobniej powinieneś podzielić go na mniejsze obiekty odpowiedzialne za poszczególne zadania. Oczywiście "dodaj/usuń/zmień" itp. traktuje się jako jedno.

Czy tak wyglądała by klasa, która jest odpowiedzialna za logowanie?
  1.  
  2. class UserAuth extends User
  3.  
  4. {
  5. var $login;
  6. var $password;
  7. __construct($login,$password)
  8. {
  9. $this->login = $login;
  10. $this->password = $password;
  11. }
  12. function login()
  13. {
  14. if (!$this->check_activated()) //Odwoluje sie do funkcji odziedziczonej z klasy User
  15. {
  16. $this->Error;
  17. throw new Exception($user['login'][1]);
  18. // Obsługując wyjątki, przejmowałbym parametry tablicy, i odpowiednio interpretował numer 'błędu'
  19. }
  20.  
  21. if (!$this->password_match()) // Jak wyzej
  22. {
  23. throw new Exception($user['login'][2]);
  24. }
  25.  
  26. if (!$login_exist) //Jak wyzej
  27. {
  28.  
  29. throw new Exception($user['login'][3]);
  30. }
  31.  
  32. if (!$this->error)
  33. {
  34. return 1;
  35. //Przechodze do klasy obslugujaca sesje?
  36. }
  37. }
  38. function logout()
  39. {
  40. //przechodze do klasy usuwajaca sesje?
  41. }
  42. }
  43.  


Pozdrawiam, Mateusz
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.