PHP OO Como armar las clases para un login y mensajeria interna

[cobolero_poseido]

Hola,

Estoy realizando un sistemita de login y mensajeria interna entre los usuarios. Mi duda es con respecto a como armar las clases para realizarlo, a grandes rasgos se me ocurren dos maneras de hacerlo:

1) Clase usuario: Entre otras cosas, arma la query para saber si existe el usuario y devuelve el string con dicha query
Clase mensaje: Entre otras cosas, arma la query con la cantidad de mensajes y devuelve el string con dicha query
Clase DB: Recibe una query y realiza la consulta

Luego, en el index.php.... instancio la clase usuario pasandole el usuario y password recibido para obtener la query, instancio mensaje y llamo al metodo para que me devuelva la query armada.

Uso el patron singleton para la clase DB, paso las queries recibidas a los metodos correspondientes de la DB para que me traiga los datos y realizo el resto del proceso.


2) Desde las clases usuario y mensaje llamo a la clase DB (tambien estaria usando el patron singleton) para realizar lo mismo.

En su opinion, cual creen que sea la mejor forma de hacerlo y que ventajas/incovenientes tendria realizarlo de una u otra forma.... espero que se haya entendido, gracias.

[pateketrueke]

¿Y tienen que ser clases/objetos necesariamente?

[bulter]

Iniciado por pateketrueke

¿Y tienen que ser clases/objetos necesariamente?

No veo por que no :/
Si son objetos es mucho mas facil de manipular, usar , mas facil de leer etc.
Ahora si empieza con 3 lineas de código en un futuro a lo mejor quiere seguir desarrollando lo y si tiene 1310923812903 funciones que ni dios sabe lo que hacen, pues lo tiene claro. Otra cosa también es que con el tiempo si tiene la estructura buena puede ir ampliando las cosas. Por ejemplo

Código PHP:

  <?php
interface IUserLogin
{
    public function Login(array $userLoginData);
    public function Logout();
}

abstract class User
{
    protected $_userName = ""; //username
    private $_additionalUserData = array(); // user data
    
    protected function ValidateUserName($username)
    {
        /// TO DO
    }
    
    protected function ValidateUserPassword($username)
    {
        /// TO DO
        return true;
    }
    
    public function getUserName()
    {
        return $this->_userName;
    }
    
    protected function AddUserData($key, $data)
    {
        // TODO: validate $key and $data
        $this->_additionalUserData[$key] = $data;
    }
    
    protected function GetUserData($key)
    {
        if(!array_key_exists($key, $this->_additionalUserData))
        {
            throw new Exception("Key not found");
        }
        
        return $this->_additionalUserData[$key];
    }
}

class MemberLogin extends User implements IUserLogin
{
    public function Login(array $userLoginData)
    {
        if(!array_key_exists("username", $userLoginData) || !$this->ValidateUserPassword($userLoginData["username"]))
        {
            throw new Exception("Username is not defined.");
        }
        
        // TO DO: Login
        $this->_userName = $userLoginData["username"];
    }
    
    public function Logout()
    {
        // TO DO: Logout
    }
}

class MemberMessages
{
    private $_member = null;
    
    public function __construct(MemberLogin $member)
    {
                if(($member instanceof IUserLogin) == false)
        {
            throw new Exception(".....");
        }

        $this->_member = $member;
    }
    
    public function getUnreadedMessages()
    {
        // TO DO
    }
}

$member = new MemberLogin();
$member->Login(array("username" => "bulter", "password" => "rofl"));
$messages = new MemberMessages($member);
$messages->getUnreadedMessages();
?>   

Bue es solo una idea nada en concreto. La idea es que tienes una clase abstracta User que tiene todas las funciones que puedan realizar y todas las variable que deban de tener todos los tipos de usuarios. Ahora si mañana quiero tener un panel de administradores puede hacer tranquilo una clases AdminLogin extends User y ya tendré todo lo necesario, aparte ya que tengo el Admin en otra clase lo puedo tener controlado en una forma completamente distinta: la DB que sea con otra estructura, usar una DB distinta , tener unas reglas diferentes que un usuario normal. Otra cosa. Pepito ya sabe como funciona MemberLogin viene y ve AdminLogin pues AdminLogin hereda User pues ya sabe que puede usar dentro las funciones ValidateUserName y getUserName también implementa el interface UserLogin sabra que la función Logout() esta disponible de una forma u otra y no poner en 20 sitios $this->Logout(); y al arrancar el script 20 Errores de que Logout no existe para Admin. El dia siguiente viene Jose y me dice "Tio quiero que las Noticias de la pagina tengan moderadores de mi empresa". Pues perfecto le doy a el acceso a la clase User y a la interfaz UserLogin y puede trabajar y yo estar tranquilo de que no tocara algo que no es cosa suya y sabre que Jose cumple con mis normas y no podra tocar nada de lo mio y de Pepito :D. Luego para cambiar digamos de un Member normal a un Admin ... facilisimo en la clase del Admin pongo otra funcion que tome de argumento objeto MemberLogin y ya tengo todos los datos del usuario ( nombre , pass , additionalData ).
Bueno es una idea básica, este teme se puede desarrollar mucho, mi idea es que es preferente usar clases/objetos y aun mas si se trabaja en equipo o con un proyecto grande.

[dashtrash]

Iniciado por bulter

Código PHP:

  <?php 
interface IUserLogin 
{ 
    public function Login(array $userLoginData); 
    public function Logout(); 
}   

Dejando aparte otras cosas menores...Esperas que algo más, que no sea la clase User, implemente el interfaz "IUserLogin"?
Si tienes una clase User, no es algo raro que exista un interfaz cuyo nombre contenga el nombre de otra clase.
Sobre que la estructura de clases esta te permita manejar permisos de acceso...Mientras sean extremadamente simples..Puede.

No se lo compliques (innecesariamente) al OP.Lo que necesita es una clase User y una clase Message.
Sobre la pregunta original (que me parece muy interesante):
Hay más opciones:
- Cómo obtienes una instancia de mensaje? Haces new Message(Usuario) o $usuario->createMessage()?
Pero, sobre todo, el método $usuario->getMessages(), esperas que te devuelva objetos de tipo Message, o una query?

[bulter]

Iniciado por dashtrash

Dejando aparte otras cosas menores...Esperas que algo más, que no sea la clase User, implemente el interfaz "IUserLogin"?
Si tienes una clase User, no es algo raro que exista un interfaz cuyo nombre contenga el nombre de otra clase.
Sobre que la estructura de clases esta te permita manejar permisos de acceso...Mientras sean extremadamente simples..Puede.

No se lo compliques (innecesariamente) al OP.

LOL ?
no es algo raro que exista un interfaz cuyo nombre contenga el nombre de otra clase.

Donde viste una clase con ese nombre ? Tienes las clases User y MemberLogin. User es general puede ser admin member mod vip etc. Y, Si espero que alguien mas la implemente y por si no has visto User no la implementa ... wtf. La implementa MemberLogin si tienes AdminLogin tambien la tendra que implementar si tienes ModeratorLogin tambien . Todas estas deben de tener definidas las funciones Login y Logout ..

Sobre que la estructura de clases esta te permita manejar permisos de acceso

No es solo que la estructura de clases te permite manejar el permiso de accesos, si fuera solo esto no existirían probablemente.

No se lo compliques (innecesariamente) al OP

Complicar el que ? Son cosas básicas de una hierarquía.

Saludos.

[dashtrash]

Iniciado por bulter

LOL ?

Eso digo yo...Lol..
Confundir interfaces con métodos...

Iniciado por bulter

no es algo raro que exista un interfaz cuyo nombre contenga el nombre de otra clase.

8-O ... Esas cosas se llaman *metodos*.De verdad.A menos que me digas que en tu sistema, hay muchas otras cosas que hacen Login.

Iniciado por bulter

Tienes las clases User y MemberLogin. User es general puede ser admin member mod vip etc. Y, Si espero que alguien mas la implemente y por si no has visto User no la implementa ... wtf

Implementa validar login y validar password, pero no implementa Login...Eso si que es un wtf...Anda como un pato, camina como un pato, pero es un pato abstracto...
Implementar no es una cuestión de si escribes el codiguito de la función o no.Sino de si tiene sentido o no.Hay algo que no sea un usuario (y eso incluye otros sistemas), que pueda hacer login? "Admin member","mod","vip" que son?.Quienes más van a implementar ese interfaz, y que esté fuera del árbol de herencia de User!?!?!
Psst.De verdad.Que es un método.

Iniciado por bulter

Complicar el que ? Son cosas básicas de una hierarquía.

Dada cualquier clase, puedes ir método a método, y convertirlos en interfaces.Mejor: todos menos uno.Ahora creas una clase abstracta que implementa todos los anteriores interfaces, y el método ese que te dejaste, lo declaras abstracto.
Y luego implementas una clase concreta, que herede de la abstracta.
Son cosas básicas de una jerarquía.Una mala jerarquía, pero una jerarquía.

[bulter]

Pero tio donde ves confundirme una interfaz con un metodo ? Y quien dijo que esta clase es entera o cualquier cosa de estas ? Pero tu lees algo de lo que escribo ? En ningun sitio digo que tiene que ser asi, solo dije por que seria mejor una cosa que sea con objetos y por que no roflmao. User dije que se una clase que tiene cosas que comparten todos los tipos de usuarios AdminLogin, MemberLogin, VipLogin aparte puedes tener MemberProfie. 1000 veces dije que este codigo no tiene AdminUser pero si lo puedes poner ...

IUserLogin es una interface que deben de implementar todos los tipos de login ... si tienes 1 pelota de futbol 1 pelota de baloncesto y 1 pelota de voleibol no tendran todas el metodo SALTAR y la variable COLOR ? y seria logico implementar una interfaz que les oblige tener el metodo saltar y la variable color

Si tienes una clase User, no es algo raro que exista un interfaz cuyo nombre contenga el nombre de otra clase.[

Otra vez te pregunto donde ves tu una clase o Metodo que tenga el nombre de un interface.

Implementa validar login y validar password, pero no implementa Login...Eso si que es un wtf

Wtf :/ ValidateUserPassword y ValidateUserName tiene la idea de comprobar si el nombre de usuario es valido en signos ... (ej: min 3 chars max 10, solo letras y digits etc.) y lo mismo de password Validar que es minimo digamos 6 chars y que contiene letras y numeros , que por dios tiene que ver esto con el login ? Esto se puede usar por el login por el register incluso por Ajax para validar en RT .... no tiene NINGUN sentido hacer un login ahi .. pone ValidateUserName no ValidateLogin or something like that ....

A ver si asi te explicas mejor lo que digo

Código PHP:

  <?php
interface IUserLogin
{
    public function Login(array $userLoginData);
    public function Logout();
}

abstract class User
{
    protected $_userName = "";
    private $_additionalUserData = array(); 
    protected function ValidateUserName($username){}
    protected function ValidateUserPassword($username) {}
    public function getUserName(){ }
    protected function AddUserData($key, $data){}
    protected function GetUserData($key){  }
}

class MemberLogin extends User implements IUserLogin
{
    public function Login(array $userLoginData){ }
    public function Logout(){}
}

class AdminLogin extends User implements IUserLogin
{
    public function Login(array $userLoginData){ }
    public function Logout(){}
}

class MemberProfile extends User { }
class AdminProfile extends User { }
class MemberRegister extends User { }

class MemberMessages
{
    private $_member = null;
    public function __construct(MemberLogin $member){}
}
?>