Patrones para la superposición de dos objetos.

Question

Estoy seguro de que esto ya se ha preguntado y respondido, así que me disculpo de antemano por ello, pero no encuentro las palabras clave correctas para buscar.La búsqueda de "Patrón" genera demasiadas preguntas y respuestas como para ser útil.

Estoy trabajando en una aplicación de prueba de regresión.Estoy mostrando un formulario en la pantalla y, según el usuario que haya iniciado sesión en la aplicación, algunos de los campos deben ser de solo lectura.Entonces puedo abstraer un objeto de campo y puedo abstraer un objeto de usuario, pero ¿qué patrón debería observar para describir la intersección de estos dos conceptos?En otras palabras, ¿cómo debo describir que para el Campo 1 y el Usuario A, el campo debe ser de solo lectura?Parece que solo lectura (o no) debería ser una propiedad de la clase Field pero, como dije, depende de qué usuario esté mirando el formulario.He considerado una matriz bidimensional simple (p.gramo.ReadOnly[Field,User] = True) pero quiero asegurarme de haber elegido la estructura más efectiva para representar esto.

¿Existe algún patrón de diseño de software con respecto a este tipo de estructura de datos?¿Estoy complicando demasiado las cosas? ¿Sería una matriz bidimensional la mejor manera de hacerlo?Como dije, si esto ha sido preguntado y respondido, pido disculpas.Busqué aquí y no encontré nada y una búsqueda en Google tampoco mostró nada.

Answer 1

Los diseños basados ​​en tablas pueden ser eficaces.Steve Maguire tuvo algunos buenos ejemplos en Escribiendo Sólido Código .

También son una excelente manera de capturar pruebas, consulte adaptar .

En tu caso algo como:

Field1ReadonlyRules = {
    'user class 1' : True,
    'user class 2' : False
}

field1.readOnly = Field1ReadonlyRules[ someUser.userClass ]

Aparte, probablemente quieras modelar ambos usuarios y clases/roles/grupos de usuarios en lugar de combinarlos.Un usuario normalmente captura OMS (autenticación) mientras se capturan grupos/roles qué (permisos, capacidades)

Answer 2

A primera vista, parece más bien que tienes dos tipos diferentes de usuarios y tienen diferentes niveles de acceso.Esto podría resolverse mediante herencia (PowerUser, Usuario) o conteniendo un objeto o token de seguridad que establezca el nivel para el usuario.

Si no le gusta la herencia como regla general, puede usar un patrón de estado en la aplicación, decorar los objetos del usuario (Shudder) o posiblemente agregar patrones de estrategia para diferentes niveles de seguridad.Pero creo que es un poco pronto todavía, normalmente no aplico patrones hasta que tengo una idea firme de cómo crecerá y se mantendrá el artículo.