Arquitectura

Clase Usuario y Roles:

• La clase usuario almacena datos y además tiene la responsabilidad de validar en el sistema al usuario, hay que aplicar el SRP.

• Cada rol, superadministrador, administrador, patrocinador y jugador tienen las mismas funcionalidades:

• Registrar

• Borrar

Aplicando el SRP debe ser encapsulado en otra clase y sea esta la que decida que rol crear dependiendo de quién tenga que registrarse.

👍 Una solución sería separar la clase Usuario en dos clases: una clase/interfaz abstracta Login y otra clase NickPassLogin que herede de ella, por ejemplo para hacer login a través del Nick y la contraseña. Si el día de mañana queremos añadir la posibilidad de hacer login a través del DNI y contraseña (DniPassLogin) o huella dactilar (DniFingerPrintLogin), solo tenemos que crear otra clase y que herede de Login.

👍 Además, añadimos un enumerado a la clase Usuario, que tendrán los valores: SuperAdministrador, Administrador, Patrocinador y Jugador, así las clases descendientes desaparecerían.

👍 Añadimos también una clase StoreLogins, que almacenará los usuarios que están logeados en el sistema actualmente. Se añadirán y/o borrarán a medida que vayan logeandose o cerrando sesión.

Tambien creamos una interfaz llamada UsuarioDAO, que tendrá los usuarios que no están en el sistema, de este heredará la clase Usuario.

• 👎 Una posible solución puede ser aplicar el patrón Factory, aunque lo veremos mas adelante si es viable o no.

• 👎 Otra posible solución es declarar la clase Usuario como abstracta y que tenga algún método abstracto. Cada rol definirá su comportamiento, no es lo mismo borrar un patrocinador que registrarlo.

Clases Juego, Torneo, Partidas

• 👍 Separar la Interfaz de Usuario (UI) del comportamiento. Juego, Torneo y Partidas almacena datos y además tienen la responsabilidad de mostrarlos por la UI. Aplicando el principio SRP hay que sacar la UI en otra clase. Será esta quién decida cómo se verán los datos.

• 👍 Aplicando el principio de SRP a las clases (Juego, Torneo y Partida) tienen la responsabilidad que en el momento en el que una va a ser creada, esta comprobará si las restricciones son correctas. Por lo que debemos separar y crear una clase para la Gestión de Juegos. Así si en algún momento cambia alguna restricción, las clases no se verá modificada en absoluto.

Persistencia

Es necesario crear una clase que separe la Base de Datos del Dominio para así seguir el modelo de 3 capas. Dicha clase será abstracta, de la que heredaran de ella la forma en la que guardaremos los registros, en principio será en Memoria, pero mas adelante tendremos que añadir una para guardarlo en una base de datos real y guardarlo de forma permanente en el sistema.

---