Cita:
Empezado por dec
Hola,
No te preocupes en absoluto Delphius. De veras, tampoco es mi intención que nadie se coma la cabeza por algo, que, en todo caso, me toca a mí. 
En serio. No era mi intención. Lo que cada uno pueda aportar bien aportado está y se agradece, pero, no es menester volverse loco por contestar a este loco.
Por otro lado, y, si todo va como espero (¡pero nunca nada va como espero!) pronto podrás echar un vistazo al código fuente del invento. 
Así que ya sabes Delphius, no te preocupes más de la cuenta.  |
Entre locos nos entedemos
No me preocupo, pero considero que este no sólo es útil para ti, sino también para mi
... porque en parte es algo que también estoy analizando desde hace tiempo y puede que ayudandote a ti, en lo que mis pocas neuronas puedan, logre comprender que es lo que falla en mi contexto.
Cita:
Empezado por dec
Tal vez podría mirarse, porque, efectivamente, resultara interesante que un "editor", en un momento dado, también pudiera administrar usuarios, sin que asumiera el rol de "administrador" sí o sí.
¡Ay! Ya sabía yo que esto no podía ser tan sencillo... |
Pues a eso mismo me refería con el uso de las reglas.
Considero que esto necesita de una pespectiva. Mirar al problema desde el dominio del negocio.
Velo así: ¿El contexto del problema indica, o da indicios, que los perfiles sean modificados a lo largo del tiempo?
¿En el contexto del problema, tiene significado que un editor administre a un usuario?
En un ambiente en donde las cosas fluctúan demasiado, y deben ser controladas se necesita de una mirada un tanto distinta: ser flexible. Por lo general... para dar cierta flexibilidad a un enfoque rígido (Por ejemplo: un usuario es administrador y siempre lo será, y hará X,Y,Z) es necesario implementar reglas de negocio que alteren o adapten a estos potenciales requisitos.
¿Como se soluciona esto?
Dezplando la responsabilidad de asignación de los permisos (combinación de funcionalidad y perfil. Véase la matriz) a una clase llamemosle Negocio. Un Negocio implementa ciertas políticas que por lo general, son cambiantes. A estas políticas las podemos formular en forma de reglas.
En forma práctica, la clase Negocio tiene como responsabilidad:
Crear Reglas
Editar Reglas
Eliminar Reglas
La clase regla lo que hace es tener registrado de alguna forma que se está permitido o no. Aquí, haría falta un análisis de como y que se necesita guardar para responder a frases como esta:
Regla de Negocio 1: Todo editor tiene la posibidad de dar de baja un texto.
¿Cómo registrar esto? Por esto digo, hace falta un análisis. Su problema es como traducir una frase gramatical a un conjunto ordenado de datos. En ocasiones basta con tener un campo que represente al sujeto (en este caso el editor), un campo que indica la condición (llamemosle permitido), un campo que reprenta al verbo o acción (baja) y un campo que represente al elemento (texto) . Algo así:
Código:
Tabla Reglas:
IDRegla - Sujeto - Permitido - Accion - Elemento
1 - Editor - NO - Baja - texto
Este modelo lo que hace es extender al simple modelo de las matriz. La matriz es un modelo rígido, y cuando se necesita alterar algo en lo particular este enfoque no sirve. La solución es implementar esta clase Regla que se comunica con las clases funciones y la clase perfiles para darle a conocer que le son permitidos o no.
¿Se entiende la idea?
Por esto te digo, que si no estás acostumbrado a UML, puede que esta sea la oportunidad...
Haste preguntas al nivel general y determina que posibles conjuntos de reglas son válidas en el contexto para determinar como enfocar al problema del mejor modo.
Disculpa por si no soy demasiado práctico... no tengo un ejemplo con el cual mostrarte. Todo lo tengo en la cabeza.
Saludos,