prawidlowe OOP , struktura klasy, Jak wedlug koncepcji OOP napisac dobra klase Opcje

[rahul]

Witam
Temat pewnie wam znany i stary jak swiat. Pisze sobie swoj cms starajac sie zrobic to obiektowo. Dotychczas przejrzalem i przeczytalem wiele artykulow dotyczacych OOP i robie sie coraz glupszy bo z tego co rozumie to zastosowan jest multum, tylko ktore to najlepsze. mam taka klase

[PHP] pobierz, plaintext 
include_once('db/db.php');
class User
 { 
	private $user_id;
	private $first_name; 
	private $last_name; 
	private $login;
	private $password;  
	private $email; 
	private $ip; 
	private $user_role; 
	private $registration_date; 
	private $db;
 
	function __construct() 
	{
		$this->db = Database::getInstance(); 
	}
 
	function setLogin($login) 
	{ 
		$this->login = $login;
	}
 
	function setPassword($password) 
	{
		$this->password = $password; 
	}
 
	function setFirstName($firstName) 
	{
		$this->firstName = $firstName; 
	}
 
	function setLastName($lastName) 
	{
		$this->lastName = $lastName;
	}
 
	function setEmail($email)
	{
		$this->email = $email;
	}
 
	function setUserRole($role)
	{
		$this->role = $role;
	}
 
	function setRegistrationDate($registration_date) 
	{
		$this->registration_date = $registration_date;
	}
 
 
	function login() 
	{
		$action = $this->db->prepare("SELECT * from users WHERE login LIKE '$this->login' 
									  AND password LIKE '$this->password'"); 
		$action->execute(); 
		$result = $action->fetchAll();
		if(count($result)== 1)
		{
			if($result[0]['Role'] == 0)
			{
				$_SESSION['user_id'] = $result[0]['user_id']; 
				return true;
			}else if($result[0]['Role'] == 1)
			{
				$_SESSION['user_id'] = $result[0]['user_id'];
				$_SESSION['admin'] = 'admin';
				header('location:admin.php');
			}
		}
		return false; 
	}
 
	function register() 
	{ 
		$ip = $_SERVER['REMOTE_ADDR'];
		$action = $this->db->query( "INSERT into users(user_id , Login , Password ,  Name , LastName ,Email , Ip , Role , RegistrationDate)
							    VALUES('' , '$this->login' ,'$this->password' , '$this->firstName' , '$this->lastName' , '$this->email' , '$ip' ,
                                                             '$this->role' , NOW())"); 
		$action->execute();
		return true;
	}
 
	function EditUser() 
	{
		...
	}
 
	function ChangePassword()
	{
		...
	}
} // end of class. 
?>
[PHP] pobierz, plaintext 

Pierwsze pytanie : Czy klasa User powinna miec funkcje takie jak Loguj, Rejestruj, Edytuj, Zmien Haslo i czy te funckje powinny miec juz "hardcoded" zapytania do bazy wewnatrz, patrz funckja loguj();. Wywoluje ja tak:

[PHP] pobierz, plaintext 
 
$user_c = new User(); 
	$user_c->setLogin($_POST['login']);
	$user_c->setPassword(md5($_POST['password']));
	$login = $user_c->login(); 
[PHP] pobierz, plaintext 

Jezeli cos tego pokroju jest ok to spoko. Teraz np dopisalem sobie taka funkcje to tej samej klasy, ktora jak dla mnie moglaby byc w kazdej prawie innej klasie :

[PHP] pobierz, plaintext 
class User { 
 
private $sqlObj; 
private $SqltableRows;
 
function query($query) 
	{
		$sql = $this->db->query($query); 
		$sql->execute(); 
		$this->sqlObj= $sql->fetchAll(PDO::FETCH_OBJ);
		$this->SqltableRows= $sql->fetch(PDO::FETCH_ASSOC);
	}
}
[PHP] pobierz, plaintext 

Dzieki tej funkcji lapie sobie wszystko z bazy i w prosty sposob moge wywolywac wszystkie kolumny :

[PHP] pobierz, plaintext 
$user_c = new User(); 
$user_c->query("SELECT * FROM users");
$users = $user_c->getObj(); 
foreach ($users as $user)
{
echo $user->Name;
echo $user->Password;
}
[PHP] pobierz, plaintext 

Bardzo podoba mi sie mozliwosc poboru rekordow i nazw wierszy tabeli w tak prosty sposob. Teraz do rzeczy :
Funckja ta jest w Users ale generalnie moglaby byc w prawie kazdej innej klasie, np Products, Articles itp. Czy mam utworzyc osobna klase z ta funckja z ktorej jakos beda kozystac wszyskie inne klasy ? Czy ma byc to w klasie bazy danych, czy moze w jakies jeszcze innej ?

Prosze o odpowiedzi i wyrozumialosc (IMG:style_emoticons/default/smile.gif)


Ten post edytował rahul 20.08.2011, 20:50:56

[thek]

@Crozin: niekoniecznie ze stanu globalnego. Kto mi zabroni tworzyć powiązanie z bazą danych dopiero w określonym momencie? Owszem... Mogę jawnie wstrzyknąć obiekt połączenia do konstruktora, ale mogę też dopiero na tamtym etapie próbować takie połączenie utworzyć na podstawie plików konfiguracyjnych. To JAK to będzie ostatecznie rozwiązane to już raczej "dalszy plan", a my skupiamy się, jak słusznie zauważyłeś, na pewnego rodzaju mapowaniu. A tym samym nas tutaj interesuje logiczna reprezentacja pewnych powiązań, a nie głębsze sięganie już pod kątem implementacji określonych wzorców czy rozwiązań, takich jak wspomniany DI©. To GDZIE i KIEDY zostanie nawiązane połączenie jest teraz akurat mniej istotne. Równie dobrze mogę na poziomie aplikacji nawiązać je i przerzucać pewną strukturę połączenia do bazy jako domyślny parametr wszelkich konstruktorów jak u jawnie. To jest rzecz, którą przemyśleć się powinno na etapie implementacji, a nie diagramów UML ogólnych (IMG:style_emoticons/default/smile.gif) Bo wiadomo, że taki obiekt musi zaistnieć, ale to w jaki sposób, jest już mniej istotne. Teraz najważniejsze jest określić to jak klasy User i UserManager są od siebie zależne, jak współpracują, jakie mają metody. Nie mieszajmy od razu do całości refleksji, która jest przydatna głównie tam, gdzie nie wiemy do końca z czym mamy do czynienia. Jeśli jest inaczej i znamy wszystko od A do Z to po co ruszać małej wydajności kobyłę do czegoś co można rozwiązać prościej. Bo chyba nie zaprzeczysz, że ruszanie tego mechanizmu w większości przypadków jest zwyczajnym marnotrawstwem zasobów.

@rahul: chcesz złapać nieco nieco idei? Najpierw zastanów się nad funkcjonalnościami i tym co się z nimi wiąże. Staraj prześledzić poruszanie po stronie/sklepie i zauważyć mniejsze cegiełki. W końcu zauważysz te najmniejsze, powiązania z większymi i to da Ci pewne spojrzenie na pewne rzeczy obowiązkowe. Gdy siądziesz, głębiej zaczniesz zauważać, że pewne rzeczy są do siebie podobne i są przykładowo szczególnymi przypadkami innych choćby czy mają zbliżone funkcjonalności. Przykład? Artykuł, Post, News... Są pewną odmianą Wpisu. Wszystkie mają pewne wspólne pola i metody. Różnią się jedynie drobnymi szczegółami. Już to daje Ci powód do użycia dziedziczenia lub narzucenia określonych interfejsów. Z biegiem czasu takie spostrzeżenia staną się naturalniejsze. Ja do dziś zanim siądę do kompa siadam z kartką papieru i długopisem rozrysowując i rozpisując sobie wszystko co wpadnie mi do głowy. Wolę spędzić kilka dni na tym i mieć potem po prostu szybkie kodzenie, niż siąść od razu do kodzenia by po kilku dniach przepisywać coś od nowa, bo nie pomyślałem o określonej funkcjonalności. Czasem jest tak, że po fakcie zauważam, iż już gotowe rozwiązanie pozwala mi na pewne zastosowania w nie planowanych sytuacjach. Jest na tyle elastyczne, że mogę je wykorzystać w innym miejscu, lub na jego bazie inny problem rozwiązać prościej. Sam niedawno zrobiłem jedną funkcjonalność w serwisie, która miała być tylko dla zalogowanych. Teraz jednak się okazało, że można ją pchnąć dla niezalogowanych, a już mi szef wspomniał, że to fajny sposób by rozwinąć pod kątem społecznościówki, jako jeden z elementów.