Modelado "Soy * pero también soy **"

Question

En [this post], estoy luchando por implementar un Patrón de estado como lo sugiere @jonp. No entiendo muy bien cómo usar lo que ha publicado, pero me lleva a pensar que tal vez estoy tratando de meter una clavija cuadrada en un agujero redondo. Así que mi pregunta:

Si tengo un visitante a mi sitio que puede desempeñar múltiples funciones es decir, un User podría ser una Vendor, un Employer, un Advertiser, o la totalidad de lo anterior, debo utilizar la herencia? He declarado:

class Vendor : User {} 
class Advertiser : User {} 

etcétera, pero cuando un usuario es a la vez un vendedor y un empleador a continuación ejemplos de diferentes clases realmente apuntan al mismo objeto subyacente ... No estoy seguro de que esto puede funcionar. ¿Cómo lo modelo?

* actualización *

gracias a todos (a todos obtiene un punto (que es todo lo que puedo dar)). He estado tirando de mi pelo sobre copias en profundidad con EF, downcasting y el patrón de estado de los últimos días. El enfoque de roles tiene mucho más sentido.

Answer 1

Esto suena como una situación a la cual el patrón de atributo (o lo que yo llamo) sería muy apropiado. Es un enfoque mucho más flexible que la herencia simple que se puede utilizar para especificar múltiples "comportamientos" o en su caso tipos de User. Realmente no es nada más complicado que un objeto que tenga etiquetas de otro tipo de objeto.

La forma más fácil de poner en práctica, sería tener una clase concreta User, con una propiedad de sólo lectura IList<UserRole> (internamente esto puede ser un campo List<T> tal vez). Su clase UserRole sería abstracta, y VendorRole/AdvertiserRole/etc. se derivaría de ello, lo que le permite etiquetar en un número determinado de roles diferentes (incluso los del mismo tipo) en un usuario determinado. Estos roles también pueden definir sus propios comportamientos personalizados, métodos de utilidad, etc.

Además, se podría definir un método GetRole<TRole> en su clase User para facilitar el acceso a las funciones de un tipo específico (suponiendo que cada User sólo tiene un único Role de un subtipo específico).

Nota al margen: también puede considerar el decorator patern, que está estrechamente relacionado con el patrón mencionado anteriormente, aunque personalmente creo que es excesivo aquí, y realmente no agrega nada en términos de flexibilidad o potencia. A menudo solo oscurece lo que estás tratando de hacer; aunque puedes investigar de todos modos.

Answer 2

Debe favorecer composición sobre la herencia si los diferentes roles tienen que contener lógica diferente que se implementa utilizando polimorfismo y métodos abstractos, por ejemplo:

public class User 
{ 
    public Role Role { get; set; } 
} 

public abstract class Role 
{ 
    abstract void DoRoleSpecificStuff(); 
} 

public class Vendor : Role 
{ 
    public void DoRoleSpecificStuff() 
    { 
     /* ... */ 
    } 
} 

public class Employer : Role 
{ 
    public void DoRoleSpecificStuff() 
    { 
     /* ... */ 
    } 
} 

public class Advertiser : Role 
{ 
    public void DoRoleSpecificStuff() 
    { 
     /* ... */ 
    } 
} 

Si un usuario puede tener múltiples funciones, considere el uso de una propiedad de colección Roles:

public IEnumerable<Role> Roles { get; set; } 

---

de lo contrario, un enumeración usando el atributo [Flags] podría estar bien, también, en función de si tiene que ser capaz de asignar múltiples roles:

public class User 
{ 
    public Roles Roles { get; set; } 
} 

[Flags] 
public enum Roles 
{ 
    Advertiser = 0x0, 
    Employer = 0x1, 
    Vendor = 0x2  
} 

Se podría asignar una combinación de diferentes funciones de la siguiente manera:

User user = new User 
{ 
    Roles = Roles.Advertiser | Roles.Vendor; 
}; 

Eso haría que el Usuario sea tanto un Anunciante como un Proveedor, pero no un Empleador.

Answer 3

"Soy * pero también soy **" se conoce como Herencia Múltiple. C# no es compatible con esto, por lo que no debería considerarlo.

Answer 4

De hecho, es la composición por herencia, pero es más como esto si un solo usuario puede tener múltiples roles.

Si hay relativamente pocas funciones, un 'estacionamiento' análogo a un resultado de combinación externa puede funcionar. En este patrón, no se requiere clase base Role.

class User 
{ 
    // all of these may be null if not applicable 
    VendorRole VendorRole { get; set; } 
    EmployeeRole EmployeeRole { get; set; } 
    AdvertiserRole AdvertiserRole { get; set; } 
} 

Si un usuario puede tener múltiples instancias de una sola función, una colección aparece:

class User 
{ 
    // all of these may be null if not applicable 
    VendorRole VendorRole { get; set; } 
    EmployeeRole EmployeeRole { get; set; } 
    ICollection<AdvertiserRole> AdvertiserRoles { get; } 
} 

Alternativamente, si puede haber un montón desordenado de los roles, si los papeles se añaden dinámicamente, o qué tienes, necesitarás una colección y un tipo de base. Si Entity Framework está involucrado, sin embargo, los roles añadidos dinámicamente me parecen poco probables.

class User 
{ 
    ICollection<Role> Roles; 
}