Sugerencias necesarias: alternativa a la sobrecarga de "es" y "como" operadores en .NET

Question

Espero que esta pregunta no se considere demasiado subjetiva - Realmente no espero una respuesta definitiva, pero espero que la opinión de todos lo haga en menos ayúdame a formar el mío.

Estoy implementando un sistema de tipo personalizado, que es un superconjunto del sistema de tipo OOP clásico. En este tipo de sistema, las instancias de objeto se pueden combinar en tiempo de ejecución para formar nuevas instancias, al tiempo que se conservan las identidades individuales.

este código:

var p = new Person(); 
var pa = new Partner(p); 

... resultados en un único objeto combinado, con "p" y "pa" ser diferentes vistas OOP conformes en él. IOW, cambiar el valor de una propiedad en una de las vistas se refleja inmediatamente en cualquier otra vista que también contenga esta propiedad.

Todo esto funciona bien y bien, pero le faltan dos API clave para consultar las identidades de tipo. Realmente me gustaría ser capaz de escribir dicho código:

if (p is Partner) 
{ 
    (p as Partner).SomePartnerProperty = "..."; 
} 

Por supuesto, esto no funciona, ya que el comportamiento de "es" y "como" operadores no se pueden sobrecargar/extendió más allá de lo que es .NET Las reglas de OOP dictan. Sin embargo, todavía necesito esta característica en mi sistema de tipos.

Lo primero que pensé fue utilizar métodos de extensión genéricos que uniría a todas las instancias de mi sistema Tipo:

public static bool Is<T>(this BaseType target) where T : BaseType { ... } 
public static T As<T>(this BaseType target) where T : BaseType { ... } 

Haciendo caso omiso de la cuestión del conflicto de nombres en idiomas mayúsculas y minúsculas, esto parece estar bien en términos de funcionalidad :

if (p.Is<Partner>()) 
{ 
    p.As<Partner>().SomePartnerProperty = "..."; 
} 

sin embargo, no puede dejar de preguntarse - ¿es realmente el mejor, API más conveniente que uno puede llegar a?

¿Cómo recomendaría implementar estos dos operadores para que se sientan naturales de usar en el código de la aplicación?

ACTUALIZACIÓN: Para cualquier persona que se pregunta acerca de la finalidad de dicho sistema de tipo ... Básicamente, cada tipo cae en una de dos categorías: Identidad o papel. En el ejemplo que di más arriba, Person is an Identity (por diseño), mientras que Partner es un rol (nuevamente, por diseño, podría haber sido diseñado de manera diferente). La regla fundamental de este tipo de sistema es que cualquier número de Roles se puede componer con cualquier Identidad dada, mientras que la Identidad misma solo se puede componer con una Identidad superior (por ejemplo, una Persona puede convertirse en un Contacto, pero nunca puede convertirse en una Compañía). Tal tipo de sistema permite que las aplicaciones traten de forma transparente, por ejemplo, Objetos asociados, independientemente de la identidad que tengan (por ejemplo, persona, empresa, banco, etc.).

Answer 1

Sugiero usar dos funciones simples.

El primero sería (al menos para mí) ser intuitivo con un nombre como:

p.IsType(typeHere) 
p.IsPartner() 

y el segundo un simple to-Call:

p.ToPartner() 

que no aplicaría los como genéricos (simplemente no me parece correcto), especialmente el último no.

Answer 2

Para mí se parece a un Partner no es un Person, sino una Partner hace tienen unaPerson. Para mí la interfaz tendría sentido como

var p = new Person(); 
var pa = new Partner(p); 

pa.SomePartnerProperty = "..."; 
pa.Person.SomePersonProperty = "..."; 

Answer 3

Para mantener un control completo sobre el proceso de conversión (y asegurando que el código se ejecuta realmente), el enfoque parece ser la más sensata. Puede usar los operadores explicit y implicit para controlar la conversión de tipo (ya sea mediante conversiones implícitas o mediante conversión explícita), pero hay suficientes "trampas" en esos sistemas para hacer que sean una opción menos que deseable para lo que parece que es intentando arquitecto.

Answer 4

Para C# Creo que su 'primer pensamiento' (por ejemplo, x.Is<T>()) se ve bien (de improviso, creo que es lo que haría).

Si va por la ruta F #, puede usar patrones activos, p.

match p with 
| IsPartner pa -> DoPartnerStuff(pa) 
| _ -> JustPersonStuff(p) 

Answer 5

sólo algunas de intercambio de ideas en línea ...

class Role { 
    public Role(Person p) { p.liRoles.Add(this); } 
} 
class Partner : Role { 
    public Partner(Person p) : base(p) {} 
} 
class Person { 
    List<IRole> liRoles; 
    public T As<T>() { 
     foreach(IRole r in liRoles){ if r is T return r; } 
     return null; 
    } 
    public bool Is<T>() { return As<T>() != null; } 
} 
var p = new Person(); 
var pa = new Partner(p); 

Esto debería permitir algo así como

if (p is Partner) 
    (p as Partner).PartnerMethod(); 

no he ejecutar esto a través de un compilador, sin embargo, por lo que podría estar completamente equivocado ;)

Answer 6

Espera ... No veo lo que está mal con el código OO normal (a menos que tengas toneladas de clase)

interface IPartner {...} 
interface IPerson {...} 
interface ICompany {...} 

class Person : IPerson {...} 
class PersonPartner : Person, IPartner {...} 
class Company : ICompany {...} 
class CompanyPartner : Company, IPartner {...} 

O supuesto, esto sería más fácil con la herencia múltiple ...

Answer 7

Mi lectura de lo que la pregunta es después sería un sistema mixin para C# - como se discutió en Is it possible to implement mixins in C#?. La conclusión es que hay algunas maneras de obtener la mayor parte de lo que una sintaxis de mixin adecuada permitiría, aunque personalmente nunca he encontrado estos resultados para dar un buen resultado de costo/beneficio.

Answer 8

He estado pensando mucho últimamente sobre estos conceptos, y sobre traits in C#. Creo que la idea que tienes para los métodos de extensión de prueba de tipo no es mucho mejor que eso (es casi exactamente lo que se me ocurrió). Tomando prestada alguna terminología del Perl 6 roles, llamaría a su método IsDoes. Pero dejaría sin cambios el As.

Pero, no creo que este uso se siente natural para lo que estamos tratando de lograr:

var p = new Person(); 
var pa = new Partner(p); 

No se ve como que va apuntan a la misma instancia. Ahora tomando prestado de Scala, tal vez algo así en su lugar?

var p = new Person(); 
var pa = p.With<Partner>(); 

De todos modos, ¿terminaste tu API? ¿Es de código abierto?