Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [OOP]Podział w klasach
Forum PHP.pl > Forum > PHP > Object-oriented programming
PawelC
26.12.2011, 15:45:56
Witam,
Zastanawia mnie jeden fakt, jak u Was wygląda tworzenie klas. Weźmy np na odstrzał klasę odpowiedzialną za obsługę użytkowników. Moje pytanie dotyczy tego, czy pakujecie wszystko co związane z użytkownikiem do jednej klasy, czy np dzielicie to w jakiś sposób.

Według mnie mądrym sposobem jest podział np obsługi użytkownika na 2 klasy. A dokładnie:
user.class.php
[PHP] pobierz, plaintext 
  1. <?php
  2. class User
  3. {
  4. 	public function viewOne($id)
  5. 	{
  6. 		//Function code
  7. 	}
  8.  
  9. 	public function viewAll()
  10. 	{
  11. 		//Function code
  12. 	}
  13. }
  14. ?>
[PHP] pobierz, plaintext


userManager.class.php
[PHP] pobierz, plaintext 
  1. <?php
  2. class UserManager
  3. {
  4. 	public function add($login, $password)
  5. 	{
  6. 		//Function code
  7. 	}
  8.  
  9. 	public function delete($id)
  10. 	{
  11. 		//Function code
  12. 	}
  13.  
  14. 	public function update($id, $login, $password)
  15. 	{
  16. 		//Function code
  17. 	}
  18. }
  19. ?>
[PHP] pobierz, plaintext

Idąc na logikę, menadżer jak sama nazwa wskazuje służy do zarządzania, czyli dotyczy tych rzeczy o których wspomniałem. Czy stosujecie podobne rozwiązanie, czy też zupełnie inne? Mnie te wydaje się dobre, z tego względu, że jest większy porządek, i łatwiej się we wszystkim odnaleźć. Ponadto takie rozwiązanie można praktycznie zastosować przy artykułach i całej reszcie.Ale chciałbym wiedzieć, co wy o tym myślicie?
skowron-line
26.12.2011, 16:58:24
Rozwiązanie raczej średnie, co to zmieni że sobie tak to podzielisz questionmark.gif. ja mam klasę modelu CRUD.
[PHP] pobierz, plaintext 
  1. /**
  2.  * Description of crud
  3.  *
  4.  * @author skowron-line
  5.  * @date 2011-12-20 22:55:56
  6.  */
  7. class Model_Crud extends Model {
  8.  
  9.     protected function insert($table, $values)
  10.     {
  11.         return DB::insert($table, array_keys($values))->values(array_values($values));
  12.     }
  13.  
  14.     protected function update($table, $values)
  15.     {
  16.         return DB::update($table)->set($values);
  17.     }
  18.  
  19.     protected function delete($table)
  20.     {
  21.         return DB::delete($table);
  22.     }
  23.  
  24.     protected function find($table)
  25.     {
  26.         return DB::select()->from($table);
  27.     }
  28.  
  29.     protected function execute($query)
  30.     {
  31.         $type = '';
  32.         switch(substr(strtolower($query), 0, 6))
  33.         {
  34.             case 'insert':
  35.                 $type = Database::INSERT;
  36.             break;
  37.             case 'update':
  38.                 $type = Database::UPDATE;
  39.             break;
  40.             case 'delete':
  41.                 $type = Database::DELETE;
  42.             break;
  43.             default:
  44.                 $type = Database::SELECT;
  45.             break;
  46.         }
  47.  
  48.         return DB::query($type, $query)->execute();
  49.     }
  50. }
[PHP] pobierz, plaintext

Wszystkie modele dziedziczą po tej klasie. I podstawowe operacje na bazie mam w jednym miejscu więc więc nie muszę pisać zapytań.
by_ikar
26.12.2011, 18:04:39
Rozwiązanie jest dobre, podobny podział jest stosowany w FOSUserBundle w symfony 2 ( https://github.com/FriendsOfSymfony/FOSUserBundle ) i sam podobnie zresztą używam, bo taka ogólna klasa średnio by zdała egzamin, ze wzgledu na to że mam jedną metodę update, która aktualizuje użytkownika jeżeli taki istnieje, lub dodaje (insert) jeżeli taki nie istnieje.
Crozin
26.12.2011, 18:12:14
Temat wałkowany już wiele razy... Google: JPA / Doctrine architecture.
ano
26.12.2011, 22:20:31
Cytat(ExPlOiT @ 26.12.2011, 15:45:56 ) *
Witam,
Zastanawia mnie jeden fakt, jak u Was wygląda tworzenie klas. Weźmy np na odstrzał klasę odpowiedzialną za obsługę użytkowników. Moje pytanie dotyczy tego, czy pakujecie wszystko co związane z użytkownikiem do jednej klasy, czy np dzielicie to w jakiś sposób.

Według mnie mądrym sposobem jest podział np obsługi użytkownika na 2 klasy. A dokładnie:
user.class.php
[PHP] pobierz, plaintext 
  1. <?php
  2. class User
  3. {
  4. 	public function viewOne($id)
  5. 	{
  6. 		//Function code
  7. 	}
  8.  
  9. 	public function viewAll()
  10. 	{
  11. 		//Function code
  12. 	}
  13. }
  14. ?>
[PHP] pobierz, plaintext


userManager.class.php
[PHP] pobierz, plaintext 
  1. <?php
  2. class UserManager
  3. {
  4. 	public function add($login, $password)
  5. 	{
  6. 		//Function code
  7. 	}
  8.  
  9. 	public function delete($id)
  10. 	{
  11. 		//Function code
  12. 	}
  13.  
  14. 	public function update($id, $login, $password)
  15. 	{
  16. 		//Function code
  17. 	}
  18. }
  19. ?>
[PHP] pobierz, plaintext

Idąc na logikę, menadżer jak sama nazwa wskazuje służy do zarządzania, czyli dotyczy tych rzeczy o których wspomniałem. Czy stosujecie podobne rozwiązanie, czy też zupełnie inne? Mnie te wydaje się dobre, z tego względu, że jest większy porządek, i łatwiej się we wszystkim odnaleźć. Ponadto takie rozwiązanie można praktycznie zastosować przy artykułach i całej reszcie.Ale chciałbym wiedzieć, co wy o tym myślicie?


Klasa User powinna reprezentować >jednego< usera. Więc daj do niej wyłącznie pola, metody związane z tym jednym obiektem.
Metody typu viewOne/viewAll powinny należeć do klasy UserManager. I wtedy
- viewOne zwraca obiekt typu User
- viewAll zwraca array (lub inny typ kolekcji) obiektów typu User.
- viewTychKtórzyDodaliPostNaForum() wink.gif < ta metoda nawet będzie potrzebowała dostęp do tabeli w DB z postami. Więc też nie myśl tak, że UserManager może operować wyłącznie na danych z tabeli Userów. Do niektórych operacji jest potrzebny dostęp do innych tabel.

Jeżeli miałbyś te metody w klasie User to nie byłoby to zbyt logiczne.

wyobraź sobie takie użycie:
[PHP] pobierz, plaintext 
  1. // tworzymy nowego usera
  2. $user = new User();
  3. $user->setFirstName("Jan");
  4. $user->setLastName("Kowalski");
  5. $user->setEmail( $user->generateEmail() ); // User::generateEmail() generuje adres na podstawie firstname i lastname i go zwraca
  6.  
  7. $userManager = new UserManager($db);  //przekazujemy instancję 'połączenia' z DB na której ma operować UserManager
  8.  
  9. // dodajemy nowego użytkownika ("rejestrujemy" go w serwisie?)
  10. $userManager->add($user);
  11.  
  12. // inne możliwości:
  13. $anotherUser = $userManager->find(42); // find wyszukuje usera na podstawie jego ID i zwraca go 
  14.  
  15. $users = $userManager->findAll(); //zwraca kolekcję userów.
  16.  
  17. foreach($users as $user) {
  18.   var_dump($user);  // byle co ;)
  19. }
[PHP] pobierz, plaintext


nie jest to w takim przypadku najbardziej oczywisty sposób rozwiązania problemu? smile.gif

pozdrawiam, Antoni
LSM
3.01.2012, 15:54:05
Zamiast klasy UserManager można użyć odrazu klasy operującej na bazie danych (dajmy na to TBUserData) w celu wyciągnięcia obiektu/tablicy z danymi o użytkowniku. Klasa taka mogłaby też zwracać obiekt $User, pełniłaby wtedy też rolę fabryki. Gdzieś czytałem opinię chieba Fowler'a, że jeśli klasa ma w nazwie słowo Manager to znaczy, że coś jest nie tak. Słowo Manager kojarzy się ze zbyt dużą odpowiedzilanością/ilością metod. Jest mało precyzyjna. Bo przez UserManager mogę określić nie tylko wynajdowanie ale archiwizację użytkownika, łączenie użytkowników, logowanie też mógłbym tam wsypać - wiele innych odpowiedzialności pasuje pod nazwę Manager. Kiedyś to nazewnictwo stosowałem, ale zarzuciłem bo takie ogólne nazwy mało mówią o faktycznej roli klasy. Zamiast UserManager dla klasy wyszukującej lepiej moim zdaniem użyć nazwy UserFinder, UserSearcher itp.
Wolę mieć: UserDataMapper {} , User{}, UserFinder{}, ObjectsColectionArchivizer {} itd.
UserManager dałbym np. klasie, która pełni rolę użytkownika z uprawnieniami do zarządzania innymi użytkownikami.
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.