Opinión sobre dividir clases

[neodani]

Buenas,

Creo que estoy pecando de centralizar prácticamente todas las funciones de mi web en la misma clase. Me gustaría saber vuestra opinión que de bien seguro tenéis más experiencia en la materia.

Hago un breve resumen de los "metodos" que actualmente tiene mi clase USUARIO

Código:

/**
 * Clase UsuarioME 
 * 	addNewUser 	-> Añadir nuevo usuario al sistema
 * 	randomKeygen -> Genera una clave aleatoria
 * 	getAge 		-> Obtiene la edad del usuario
 *	nickDisponible -> Comprueba si el nick está disponible  
 * 	correoDisponible -> Comprueba si el correo está disponible
 *	activarCuenta -> A partir de un nombre de usuario y su clave de activación, 
					pone a 1 la casilla user_activado de la BD
 * autocompletarReferido -> Sugerir referido de la BD
 * login -> Autentificación de usuarios a través del formulario de login	
 * log_login -> Guarda un registro en la BD de cuando inició sesión el usuario y actualiza el user_lastvisit
 * verifica_sesion -> Autentificación del usuario a través de la cookie "recuerdame", (no cerrar sesión)
 * logout -> Cerrar sesión, destruye cookies y crea registro en la base de datos diciendo que el usuario 
			ha abandonado su sesión	
 * resetPassword -> Inserta en la tabla log_actividad que el usuario ha solicitado el restablecer su contraseña	
 * GetDatosUser -> Obtiene los datos del usuario a partir del user_id, user_mail o user_login
 * getUserActivacionKey -> Obtiene la clave de activación del usuario
 * changePassword -> Cambia la clave del usuario
 * getTotalRegistrados -> Cuenta el número de usuarios registrados (activos/inactivos)
 */

Dividiríais los métodos en varias clases, en cuales?

Muchas gracias de antemano!

[JaimeSavines]

Los objetos no estan aislados, generalmente interactuan con otros objetos y muchas veces esa relacion en conjunto crea comportamientos mas complejos por es importante decidir cuales son los alcances y limites de los objetos que conviven en nuestro modelo y como en todas las cosas existen practicas que te ayudan a tomar esa desicion basada en practicas que normalmente se usan para eso. te recomiendo que leas sobre los patrones GRASP te dejo la liga de la wiki pero tambien si puedes al final viene el titulo del libro de Craig Larman que es el que menciona y le da nombre a esos patrones ademas de abordar otros temas que podrian servirte.
[URL="http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29"]GRASP[/URL]

Saludos

[neodani]

Iniciado por JaimeSavines

Los objetos no estan aislados, generalmente interactuan con otros objetos y muchas veces esa relacion en conjunto crea comportamientos mas complejos por es importante decidir cuales son los alcances y limites de los objetos que conviven en nuestro modelo y como en todas las cosas existen practicas que te ayudan a tomar esa desicion basada en practicas que normalmente se usan para eso. te recomiendo que leas sobre los patrones GRASP te dejo la liga de la wiki pero tambien si puedes al final viene el titulo del libro de Craig Larman que es el que menciona y le da nombre a esos patrones ademas de abordar otros temas que podrian servirte.
[URL="http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29"]GRASP[/URL]

Saludos

Si yo quiero que interactuen, pero no sé en qué otros objetos dividirlos... con esos métodos se os ocurre varias formas de dividirlos? teniendo en cuenta que en casi todos ellos hago uso de una conexión a la base de datos.

Y sobre el diseño UML he leído pero no veo cómo aplicarlo en este ejemplo.

Muchas gracias de antemano

[masterpuppet]

Que tal neodani, te dejo la referencia a los patrones,

1. Active Record(el que esas utilizando o alguna variante de este)
2. Table Data Gateway
3. Row Data Gateway
4. Data Mapper

Cada patrón tiene el respectivo diagrama que te va dar una idea clara de que podes hacer, Active Record lo utiliza adodb, Table Data Gateway + Row Data Gateway son los que utiliza Zend, en el componente Zend_Db y Data Mapper lo utiliza Doctrine 2, si queres ver implementaciones podes ir directamente a las diferentes fuentes.

Saludos.

[limbvirgin]

En mi opinión, sí deberías separar ciertos métodos a fin de dar más y mejor identidad a tu clase.

Por ejemplo, puedes tener una clase específica, llamada MyUser, que contenta los métodos relativos a un usuario a la vez: supón que me llamo Oscar, por ende la clase MyUser estará ligada (en su momento, cuando cargues los datos de Oscar - desde la base de datos - a la clase MyUser).

Class MyUser.
getAge
GetDatosUser
getUserActivacionKey

Si te fijas, esto puede traducirse a que "oscar" le puedes hacer un getAge, o un GetDatosUser, o un getUserActivacionKey, pues son datos propios de una entidad (en este caso el usuario "oscar").

changePassword también podría ir en esa clase, aunque es una acción bastante más propia del Sistema que de Oscar. Todo depende de la lógica que implementes. Yo lo agregaría a la clase MyUser. Login y logout no.
Eso lo dejaría en otra interfaz que bien pudiera llamarse "class System", encargada de los login, LogOut, cookies, y variables de sesión ($_SESSION[ ] ), también de escritura y lectura de ficheros en el servidor, escritura de logs. etc.

getTotalRegistrados, si te fijas, yo no puedo decir "Oscar"->getTotalRegistrados(); (recuerda que cuando digo "oscar" es sinónimo de la clase MyUser). Entonces MyUser, como se trata de un objeto, no puede saber cuántas personas están registradas. La consulta debe devolver la suma de una -COLECION- de datos. Por tanto debería pertenecer a una clase encargada de generalidades y colecciones de datos, por ejemplo:

Class UsersTable.
*getTotalRegistrados
*correoDisponible -> la función deberá buscar en una -colección- de objetos si el correo está disponible, por eso está aquí.
*nickDisponible -> misma descripción que la anterior.
*addNewUser -> puede estar aquí, o puede estar en MyUser.

Generalmente cuando se trabaja con POO, y base de datos relacionales, se suele implementar la lógica de mapear las entidades - que han sido definidas en la base de datos - en objetos manejables por PHP (en nuestro caso).

Por ejemplo, la clase MyUser, la declararía así.
class MyUser {
private id;
private nombre;
private edad;

#los setters
public function setId($id){
$this->id=$id;
}
#los demás setters para las demás columnas o atributos
#los getters.
public function getId(){
return $this->Id;
}
#a como había dicho, agregar un nuevo usuario puede ser implementado aquí directamente:
public function save(){
$existe=UsersTable::find($this->id);
if($existe==false)
UsersTable::addNewUser($this->id, $this->nombre, $this->edad);
else
UsersTable::updateUser($this->id,$this->nombre,$this->edad);
}
}


Espero esto te ayude un poco. Sigue leyendo patrones de POO. Ahorita estoy en plena fase de aprendizaje de Symfony, y a través de los libros he aprendido mucho. (así que esto no lo inventé yo, jojojo, ya estaba inventado cuando llegué ;)

Saludos y suerte!

[neodani]

Wow! muchas gracias limbvirgin precisamente busca un ejemplo así para verlo más claro. Voy a anotar tus comentarios para ver como implementarlo.

Muchas gracias