yoyo rozbudowywuje moj form builider & admin generator o wlasne logowanie i acl.

Poki co zanim zaczne implementowac cokolwiek chcialem zapytac sie jak to najlepiej zrobic.
Klase do obslugi acl juz mam brakuje mi tylko ogolnego logowania.
Nie jest to w mvc/mvp bo sam form builider i admin generator generuja kod html na podstawie duzo czynnikow a z poczatku "projekt" mial byc komponentem do mojego fw, jednak przeportowalem to tak zeby dzialalo nie zaleznie od "srodowiska".

A wiec logowanie ma byc elastyczne w sensie ze ma umozliwiac generalny schemat logowania ale oprocz tego zeby mozna bylo napisac swoj wlasny sterownik autoryzacji...inna struktura tabeli/inna baza/pliki i co jeszcze mozna wymyslec wazne zeby wszystko opieralo sie na wspolnym "api"(interfejsach) i zwracalo w porzadany sposob z tablica acl.

Pomyslalem zeby tez byla generalna klasa User ktora udostepnialaby o nim informacje, ustawiala pewne dane, zeby byla takim ogolnem kontenerem na obiekt typu User.

Mam tylko dylemat czy oprzec to na interfejsach czy tez na klasie abstrakyjnej lub na tej ostatniej(bazowa funkcjonalnosc) z domieszka interfejsow.

Hehe takie gdybanie...

[PHP] pobierz, plaintext 
<?php
 
interface IUser
{
	public function get_by_id($id);
	public function get_by_login($login);
	public function get_login();
	public function get_role();
	public function get_ip();
	public function get_browser();
	public function get_time();
	public function set_login($login);
	public function set_password($pwd);
	public function set_id($id);
	public function set_hash($hash);
}
 
?>
[PHP] pobierz, plaintext 

Myslalem o takim czyms prosze nie zwracac uwagi na nazwy metod (rzucilem tak na szybko idea i ich standard !sic CamelCase) gdzie glowna klasa wczytywala by sterownik ktory musialby implementowac ten interfejs.Czy jest to spojne?Do tej pory nie mialem problemow z implementacja ale jakos Obsluga uzytkownika chce zeby byla napisana dobrze.

To samo jest chodzi o klase Auth czyli interfejs,glowna klasa i sterownik(czy adapter jak to chcecie nazwac).

Jak wy to zalatwiacie?Fajnie by bylo gdyby odp byly razem z kawalkami kodu czy cos

Ja, gdy nie korzystam z ORMa i piszę takie klasy-kontenery nie tworzę im interfejsów. Po prostu nie wydaje mi się, żeby kiedykolwiek zaszła potrzeba podmiany implementacji takiej klasy. A jeśli potrzebuje trochę więcej zróżnicowania, to robię zwykłe dziedziczenie, np. AdminUser i BannedUser dziedziczące po nieabstrakcyjnej User.

Ty w swojej klasie masz metody get_by_id i get_by_login. Jeśli dobrze rozumiem, to te metody nic nie zwracają, tylko uzupełniają pusty obiekt User, na którym zostały wywołane. Osobiście rozbiłbym to na 2 klasy, ale jak chcesz mieć tak jak teraz, to powinieneś stosować interfejs/klasę abstrakcyjną. Tutaj potrzeba podmiany implementacji jest już większa (pobieranie danych z bazy, pliku XML, CSV, itp.)

Co do implementacji interfejsu vs. dziedziczenia po klasie abstrakcyjnej, to przypomnij sobie jakie są między nimi różnice (interfejsy "nie mają kodu", można dziedziczyć tylko po 1 klasie, itd.) i wybierz tą metodę, która będzie wygodniejsza. Ja w większości przypadków stosuję interfejsy, a klasy abstrakcyjne tylko wtedy, gdy czuję że będzie to właściwe rozwiązanie. Nie wiem co wchodzi w skład takiego czucia, więc ci tego nie napiszę. Pewnie będziesz musiał wdepnąć kilka razy w niepoprawne użycie klasy abstrakcyjnej, żeby to załapać

W tym wypadku, jako że masz tu oprócz tych nieszczęsnych 2 metod same pola opakowane w gettery i settery oraz jako że nie wydaje mi się, żeby klasa uzytkownika musiała dziedziczyć po czymkolwiek, użyłbym klasy abstrakcyjnej UserBase i dziedziczące po niej DatabaseStoredUser, XmlStoredUser, itd. Wygląda to... średnio, ale tak jak mówiłem, rozbiłbym to na 2 klasy.