[OOP] konstruktor ? Opcje

[piraciq]

Witam,

Może to i nie miejsce na to, a może i tak? Takie pytanie teoretycznie:

Czy w konstruktorze klasy należy umieszczać wszystkie dane które trafiają do klasy czy tylko te które ulegają przetworzeniu przez tą klasę??

pozdrawiam

[skowron-line]

Takie które trafiają do klasy przy tworzeniu obiektu.

[mike]

Konstruktor klasy służy do skonstuowania obiektu. Co oznacza że powinieneś przekazać do niego tylko te dane, która są wymagane do powstania instancji.

[piraciq]

dajmy na to przy rejestracji usera::


login haslo w zasadzie tyle wystarczy prawda

ale jesli mamy w formularzu rejestracji inne pola komunikator stronę www??

[mike]

dajmy na to przy rejestracji usera::
login haslo w zasadzie tyle wystarczy prawda

Źle.

Załóżmy że rejestrujesz za pomocą klasy User. Do stworzenia takiego obiektu wcale nie potrzebujesz hasła czy loginu.
Powinno byc raczej rak:

[PHP] pobierz, plaintext 
<?php
 
/* @var $user User */
$user = new User();
$user->setName('użytkownik');
$user->setPassword('hasło');
$user->registerNewUser();
 
?>
[PHP] pobierz, plaintext 

[piraciq]

Źle.

Załóżmy że rejestrujesz za pomocą klasy User. Do stworzenia takiego obiektu wcale nie potrzebujesz hasła czy loginu.
Powinno byc raczej rak:

[PHP] pobierz, plaintext 
<?php
 
/* @var $user User */
$user = new User();
$user->setName('użytkownik');
$user->setPassword('hasło');
$user->registerNewUser();
 
?>
[PHP] pobierz, plaintext 

chodzi mi o sam konstruktor klasy "user" co w takim przypadku powinno sie w nim znajdować bo z tego co Ty napisałeś domyślam się, że w konstruktorze się nic nie znajduje tak

[PHP] pobierz, plaintext 
<?php
public function __construct
{}
?>
[PHP] pobierz, plaintext 

[mike]

W podanym przez Ciebie przykładzie tak, konstruktor byłby pusty. Ale to wszystko zależy czym u Ciebie jest User i jak działa.
Wystarczy przykład lekko zmodyfikować i masz konstruktor wypełniony.

[PHP] pobierz, plaintext 
<?php
 
class User {
	private $name;
	private $password;
	private $gg;
	// ... etc
 
	public function __construct($id = null) {
		if ($id !== null) {
			$user = User::retrieveById($id);
			$this->fillUser($user);
		}
	}
 
	public static function retrieveById($id) {
		// funkcja pobiera z bazy danych użytkownika i zwraca go jako obiekt
	}
 
	public function fillUser(User $user) {
		// funkcja wypełnia pola obiektu polami z przekazanego obiektu;
	}
 
}
 
?>
[PHP] pobierz, plaintext 

I teraz możesz zrobić:

[PHP] pobierz, plaintext 
<?php
 
// nowy użytkownik
$newUser = new User();
 
// pobranie istniejącego użytkownika
$existingUser = new User(12);
// wykonanie poyższego konstruktowa byłoby tym samym co:
$existingUser = User::retrieveById(12);
// ale to w końcu przykład
 
?>
[PHP] pobierz, plaintext 

Jak widzisz do konstruktora przekazuje się to co jest potrzebne a nie tyle ile się da. Czasem oczywiście do stworzenia obiektu nic nie jest potrzebne.
Wtedy konstruktor nic nie robi. i może być pusty lub w ogóle może go nie być.

[piraciq]

Dzięki za nakierowanie mnie :]

jeśli napotkam na jakieś pytania napiszę jeszcze raz dzieki

[Sedziwoj]

To co podał mike jest ładnym przykładem (sam bym podał gdybym był wcześniej, ach ten Propel ), ale ogólnie zasiada jest taka, że projektujesz sobie jakiś obiekt, i wiesz że nie może on zacząć działać bez pewnych danych, więc aby wymusić aby zawsze były, przyjmujesz w konstruktorze.
Tak jak masz definicję klasy obsługującej jedno połączenie, to wiadomo, że potrzebne jest do czego się łączy (czy to soap czy pdt ), oczywiście można dać metodę która to ustawia, ale przez to zawsze musiał byś sprawdzać czy już zostało podane, czy jeszcze nie. Ale jest zasada, konstruktor (jak i każda metoda) muszą być jak najprostsze, czyli jak już coś przyjmujesz, to staraj się jak najmniej, tyle ile jest niezbędne.

Ten post edytował Sedziwoj 14.07.2008, 20:32:39

[piraciq]

W przypadku klas do obsługi baz danych to jest dla mnie zrozumiałe co się znajduje w konstruktorze klasy. Ale właśnie mam problem ze zrozumieniem tej filozofii kiedy przekazywać dane do konstruktora a kiedy nie?? Jest na to jakaś reguła czy nie

[mike]

Jest reguła. Powtórzę: przekazujesz to co jest niezbędne.
A niewiele rzeczy jest niezbędnych, więc staraj się być minimalistą w tym zagadnieniu.

[piraciq]

No to zobaczymy co mi z tego wyjdzie :]

[PHP] pobierz, plaintext 
<?php
class register extends sql
{
 
 
	public function __construct($email,$pass,$pass_replace,$nick,$minlenghtpass)
	{
		$this->user_email=trim($email);
		$this->user_pass=trim($pass);
		$this->user_pass_replace=trim($pass_replace);
		$this->user_nick=trim($nick);
		$this->minlenghtpass=$minlenghtpass;
	}
	private function licz_wiersze($query)
	{
		return mysql_num_rows($query);
	}
	public function sprawdz_email_w_bazie($email)
	{
	   
		$zap=$this->query("select user_email from users where user_email='".$this->user_email."'");
		return $this->licz_wiersze($zap);
   
	}
   
	public function poprawnosc_email ($email)
	{
		if (eregi("^[_a-z0-9-]+(.[_a-z0-9-]+)*@[a-z0-9-]+(.[a-z0-9-]+)*(.[a-z]{2,4})$",$email))
		{
			return true;
		}
		else
		{
			return false;
		}
	   
	}
	public function dlugosc_hasla ($pass)
	{
		if (strlen($pass)<=$this->minlenghtpass)
		{
			return false;
		}
		else
		{
			return true;
		}
	}
	public function sprawdzanie_hasla($pass,$pass_replace)
	{
	   return ($this->user_pass==$this->user_pass_replace ? true : false )
 
	}
 
}
 
$register= new register($_POST['email'],$_POST['pass'],$_POST['pass_replace'],$_POST['nick'],'5');
?>
[PHP] pobierz, plaintext 

i czy tu jest za dużo zmiennych przekazywanych do konstruktora

Ten post edytował piraciq 17.07.2008, 14:13:15

[Cysiaczek]

Nie, może być tak, choć ja bym się zastanowił nad przekazaniem tablicy zamiast osobnych argumentów.
Taka rejestracja ma charakter potencjalnie zmienny, więc array byłby na pewno lepszy

Pozdrawiam.

[wlamywacz]

Łatwiej chyba takie coś:

[PHP] pobierz, plaintext 
<?php
public function setParam($name, $param) {
 
		$this->$name = $param;
	}
 
	$db = new db;
	$db->setParam('user', $ini_array['mysql']['user']);
	$db->setParam('pass', $ini_array['mysql']['pass']);
	$db->setParam('name', $ini_array['mysql']['name']);
	$db->setParam('host', $ini_array['mysql']['host']);
	$db->connect();
?>
[PHP] pobierz, plaintext 

Poza tym nie rozumiem czemu dziedziczysz klasę odpowiedzialną za bazę danych ?

Ten post edytował wlamywacz 17.07.2008, 19:24:04

[Sedziwoj]

@piraciq
Pomijam konstruktor, bo jak patrzę na takie coś, to się zastanawiam po co ten obiekt, chyba tylko aby był.
Przecież jak tworzysz obiekt, to po to aby ułatwić sobie życie, a to co prezentujesz, to zebranie funkcji i zmiennych w jedno pudełko.
Co do propozycji tablicy, to moim zdaniem jest to nie eleganckie, wiadomo jak obiekt obrabia dane z POST/GET to ma tablice, ale dalej dane o konkretnej strukturze, powinny być inaczej rozpowszechniane. Czy to przez obiekt danych (w tym przypadku, nadmiar formy, nad treścią), czy też po prostu przekazywane pojedynczo przez set'ery. A taki obiekt rejestracji jak dostaje te dane to od razu je sprawdza, czy są poprawne, nie ktoś kto go używa ma sam "uruchamiać" sprawdzanie.

[Cysiaczek]

Może i tablica do konstruktora to nie najlepszy pomysł, ale już tablica przez setter wydaje mi się sensowna. Sprawdzasz wtedy strukturę takiej tablicy i masz wszystko w jednym miejscu. Troszkę jak propelowe fromArray() przy wypełnianiu obiektu. Uważam, że zwłaszcza przy obiektach, które nie są udostępniane użytkownikowi jako interfejs, takie coś doskonale przyspiesza. Można się też pokusić o specjalny obiekt zamiast tablicy - Parameters
heh, tylko po co tutaj...

[piraciq]

Łatwiej chyba takie coś:

[PHP] pobierz, plaintext 
<?php
public function setParam($name, $param) {
 
		$this->$name = $param;
	}
 
	$db = new db;
	$db->setParam('user', $ini_array['mysql']['user']);
	$db->setParam('pass', $ini_array['mysql']['pass']);
	$db->setParam('name', $ini_array['mysql']['name']);
	$db->setParam('host', $ini_array['mysql']['host']);
	$db->connect();
?>
[PHP] pobierz, plaintext 

Poza tym nie rozumiem czemu dziedziczysz klasę odpowiedzialną za bazę danych ?

to był przykład książkowy dziedziczenie klas, każde wskazówki są mile widziane :]
dzięki

opierałem się na tym

[Neojawor]

może trochę się czepiam i nie na temat, ale masz kod:

[PHP] pobierz, plaintext 
<?php
private function licz_wiersze($query)
    {
        return mysql_num_rows($query);
    }
?>
[PHP] pobierz, plaintext 

wszystko w nim dobrze, ale mysql_num_rows wymaga jako parametru wyniku zapytania, a parametr $query sugeruje, że będziesz chciał tam wsadzić treść zapytania.

Wracając do tematu, to register nie pasuje mi na klasę. Klasa ma być opisem jakiejś rzeczywistej rzeczy, a register to czynność. IMHO bardziej pasuje tu stworzenie klasy user, który będzie miał metodę register dodającą obiekt tej klasy do bazy.

[mecenas]

w kwestii konstruktora - jest to kwintesencja OOP i w zasadzie bez tego nie można mówić o obiektowości.
Jaki jest sens konstruktora w oderwaniu od baz danych? Ma dokładnie takie samo znaczenie. W razie poważniejszych problemów ze zrozumieniem tego polecam lekturę teorii innych języków obiektowych - być może wyjście z poletka php ułatwi zadanie, a przecież w wielkim stopniu język jest sprawą wtórną

btw - witam

[Cysiaczek]

Również witam

w kwestii konstruktora - jest to kwintesencja OOP i w zasadzie bez tego nie można mówić o obiektowości.

Czyli jak nie ma konstruktora, to nie ma OOP? Wybacz, ale jestem w stanie napisać kod w pełni obiektowy bez użycia choćby jednego konstruktora, więc dziwne masz to kryterium obiektowości.