Witam.

Mam pewien dylemat dotyczący konstruktora i parametrów metody.
Mam klasę Auth a w niej konstruktor który za parametry przyjmuje $login, $password, $email, $connect. Rozmawiając z moderatorem tego forum (blooregard) powiedział mi, że najlepiej gdyby konstruktor był wywoływany już przy utworzeniu obiektu. Bo wtedy wiadomo o jakie zmienne chodzi np. $this->login = $login

Ale może pokażę na przykładzie:

[PHP] pobierz, plaintext 
<?php
class Auth
{
	private $login;
	private $password;
	private $connect;
	private $email;
 
	public function __construct($login, $password, $email, $connect)
	{
		$this->login = $login;
		$this->password = $password;
		$this->email = $email;
		$this->connect = $connect;
	}
 
	#Rejestracja
	public function Register($login, $password, $email, $connect)
	{
		#kod
	}
 
	#Logowanie
	public function Login($login, $password, $connect)
	{
		#kod
	}
 
	#Przypomnienie hasła
	public function LostPassword($email, $connect)
	{
		#kod
	}
 
	#Wylogowanie
	public function Logout()
	{
		#kod
	}
}
 
?>
[PHP] pobierz, plaintext 

Problem polega na tym, że wywołując konstruktor muszę mieć przekazywane jako parametry tego konstruktora, ale co jeśli dopiero chcę utworzyć obiekt i jeszcze nic nie mam a dopiero później są przekazywane jakieś wartości? Mówię tu o późniejszym wykorzystaniu metod np. Login gdzie potrzebuję $login, $password, $connect. Najpierw wypadałoby wywołać obiekt klasy, a następnie później wywoływać potrzebne metody. Klasa bez konstruktora jest dobrą klasą? Czy umieszczanie na początku każdej metody $this->login = $login; to dobre rozwiązanie w momencie gdy usunę konstruktor? Bo pisząc kod przypomina to trochę pisanie pisanie najzwyklejszych funkcji oprawionych w obiektówkę...

Dopiero zaczynam z obiektowym PHP i jeśli możecie to proszę o jak najprostsze wyjaśnianie pewnych rzeczy

Źle mnie zrozumiaeś

Konstruktor JEST wywoływany automatycznie w momencie tworzenia obiektu.
Ja Ci zasugerowałem, byś jako jego parametry przekazywał te wszystkie zmienne i w nim inicjalizował składowe klasy tymi wartościami.

A obiekt możesz utowrzyć, gdy wartości tych zmiennych są znane.
Jeśli już musisz utworzyć go zanim znasz wartości zmiennych, konstruktor zostaw pusty i dodaj metodę, która będzie inicjalizowała składowe klasy przekazanymi wartościami (tzw. setter).

Hmm, skoro już w konstruktorze przekazujesz wszystkie loginy, emaile i co tam jeszcze masz z formularza, to do metod Register, Login itd nie musisz tego robić (chyba że cały system umieścisz w konstruktorze, co jest bez sensu). Ja bym pousuwał parametry metod Register, LostPassword, Login, ba sa niepotrzebne, poza tym nie przekazywałbym tych danych w konstruktorze, ale to już chyba zależy od własnego widzimisię.

Jak dla mnie klasa Auth powinna odpowiadac logowaniu/wylogowywaniu a rejestracja i zapomniane haslo w osobnej klasie Register.Reszta rzeczy zwiazanych z user'em powinna byc w klasie Profile, przynajmniej ja tak to widze.

W sumie czy do ustawiania danych uzylbym setterow czy konstrktora to zalezy jak komus bardziej pasuje, czasami lepiej jest jednak uzyc setterow wedlug mnie, ale w tym przypadku jest to zbedne.

Do tego zamienilbym te atrybuty z private na protected :]

blooregard ja rozumiem, wiedziałem o co Ci chodziło tylko nie widziałem innego rozwiązania związanego z metodami, jak inaczej korzystać z metod nie przekazując do nich żadnych wartości przez parametry...

Możecie mi pokazać w jaki sposób wyglądałoby użycie metod po wywołaniu obiektu i sama konstrukcja klasy i ich metod? Nadal taka sama konstrukcja tylko bez parametrów metod?

No jeżeli byś zrobił tak jak ja bym zrobił to kod wyglądał by np. tak (wyw. obiektu)

[PHP] pobierz, plaintext 
 
$obAuth = new Auth;
$obAuth->setLogin($login);
$obAuth->setPassword($password);
//itd
$obAuth->Register();
 
[PHP] pobierz, plaintext 

Jeżeli zostały by dane z forma ustawiane w konstruktorze to

[PHP] pobierz, plaintext 
$obAuth=new Auth($login, $password, $email); //itd
$obAuth->Register(); //bez parametrow
 
[PHP] pobierz, plaintext 

Rozumiem... Pewnie ilu programistów tyle zwolenników jednej czy drugiej metody ale która jest najlepsza? Najbardziej optymalna, właściwa, poprawna?

Poprawne sa obie, co do kwesti wydajnosci to ci nie powiem choc mysle ze przez kontruktor.
Wlasciwa zalezy w jakim kontekscie musisz uzyc w tym wedlug mnie obie metody sa prawidlowe.

Mam jeszcze pytanie odnośnie sposobu w którym przekazuje się wszystko do konstruktora (a nie poprzez parametry metod). Co jeśli będę miał skrypt tylko logowania i chcę wykorzystać metodę logowania a tam muszę podać tylko login, hasło i połączenie. Konstruktor wywali błąd bo potrzebne są 4 parametry, w tym email który podczas logowania nie będzie wymagany. Więc co teraz? Wychodzi na to, że wtedy nie używać konstruktora... czy może macie jakieś inne pomysły?

hmm możesz zastosować coś takiego

[PHP] pobierz, plaintext 
public function __construct($login, $haslo, $email=false, $connect)
{
 
}
[PHP] pobierz, plaintext 

Ale ja bym przebudował tę klasę, albo rozbił na kilka klas.

Do konstruktora przekazuje się parametry które są niezbędne do utworzenia obiektu. W Twoim przypadku wg mnie tylko połączenie z bazą danych jest niezbędne, gdyż jest wykorzystywane przez każdą metodę. Reszta powinna być przekazywana do odpowiednich metod.

Według mnie, jeśli przewidujesz że będzie możliwość wykorzystania obu metod warto zaimplementować je obie. Czasami jest tak, że przed tworzeniem instancji klasy znasz już wszystkie parametry, więc skorzystasz z przekazania parametrów za pomocą konstruktora, w innym przypadku najpierw utworzysz instancję a później przekażesz sobie parametry przy pomocy setterów.

Jeżeli twoje pytanie jest czysto teoretycznie to odpowiedź jest prosta. Konstruktor jest DOBRY, setter jest ZŁY. Zdecydowanie.

Argument którego użyłeś ,że chciał bys najpierw zrobić coś z obiektem a dopiero potem ustawić jego stan (jakąś jego zmienną) jest postawieniem sprawy na głowie. To jak byś powiedział: "Chciał bym najpierw pojeździć samochodem a dopiero potem do niego wsiąść." .

W większości przypadków należy inicjalizować co się da w konstruktorze. Jeżeli widzisz sytuacje w której twój obiekt może się obejść bez części zainicjalizowanych pól to najprawdopodobnej próbujesz stworzyć jeden obiekt tam gdzie powinienś tworzyć dwa (lub więcej).

W praktyce sam urzywam setterów jeśli trzeba dokoptować jakąś funkcjonalność do obiektu. Jeśli mam czas i okazje na refaktoring to rozbijam obiekty, a settery tępie jak karaluchy , mało który się uchowa...