¿Se puede usar la nueva palabra clave C# para expandir las propiedades en una interfaz?

Question

Entiendo cómo la palabra clave "nueva" puede ocultar métodos en una clase derivada. Sin embargo, ¿qué implicaciones tiene para las clases que implementan interfaces que usan la palabra clave?

Considere este ejemplo, donde decido expandir una interfaz haciendo sus propiedades de lectura/escritura.

public interface IReadOnly { 

    string Id { 
     get; 
    } 
} 

public interface ICanReadAndWrite : IReadOnly { 

    new string Id { 
     get; 
     set; 
    } 
} 

entonces usted es capaz de hacer cosas como esta:

public IReadOnly SomeMethod() { 
    // return an instance of ICanReadAndWrite 
} 

Es este mal diseño? ¿Causará problemas para mis clases implementar ICanReadAndWrite?

Editar: Aquí está un ejemplo artificioso de por qué yo podría querer hacer algo como esto:

Decir que tengo una clase de fábrica que devuelve un IShoppingCartItemReadWrite. Luego puedo tener una capa de servicio que manipula precios, cambia cosas, etc. Entonces, puedo pasar estos objetos como IShoppingCartItemReadOnly a algún tipo de capa de presentación que no los cambie. (Sí, lo sé técnicamente can cambiarlos-- esta es una pregunta de diseño, no de seguridad, etc.)

Answer 1

No es una idea particularmente mala. Debe tener en cuenta que el implementador puede (si implícitamente implementa la interfaz, entonces una sola lectura/escritura de propiedad podría satisfacer ambas interfaces) proporcionar dos implementaciones distintas:

class Test : ICanReadAndWrite { 
    public string Id { 
     get { return "100"; } 
     set { } 
    } 
    string IReadOnly.Id { 
     get { return "10"; } 
    } 
} 

Test t = new Test(); 
Console.WriteLine(t.Id); // prints 100 
Console.WriteLine(((IReadOnly)t).Id); // prints 10 

Por cierto, en general, la new El modificador de herencia no hace nada excepto decirle al compilador que se calle y no arroje una advertencia de "usted está ocultando ese miembro". Omitirlo no tendrá ningún efecto en el código compilado.

Answer 2

No estoy seguro de si compila o no, pero no es un patrón aconsejable. Con la capacidad de realizar una implementación de interfaz explícita, en teoría podría proporcionar dos implementaciones completamente diferentes para el IReadOnly y el modelo ICanReadAndWrite de la propiedad Id. Considere la posibilidad de modificar la interfaz ICanReadAndWrite agregando un método setter para la propiedad en lugar de reemplazar la propiedad.

Answer 3

Esto es perfectamente legal y las implicaciones para su clase que implementa la interfaz ICanReadAndWrite sería simplemente que cuando se trata como IReadOnly solo puede leer, pero cuando se trata como ICanReadAndWrite podría hacer ambas cosas.

Answer 4

Puede hacerlo, pero no estoy seguro de lo que espera lograr al hacerlo.

public IReadOnly SomeMethod() { 
    // return an instance of ICanReadAndWrite 
} 

Este método devolverá una referencia a un IReadOnly lo que significa que no importa que haya devuelto un ICanReadAndWrite. ¿No sería este enfoque mejor?

public interface IReadOnly 
{ 
    String GetId(); 
} 

public interface ICanReadAndWrite : IReadOnly 
{ 
    String SetId(); 
} 

Answer 5

Usted no debe poner en práctica el ICanReadWrite basado en IReadOnly, pero en lugar de hacer los separan.

es decir.de esta manera:

public interface IReadOnly 
{ 
    string Id 
    { 
     get; 
    } 
} 

public interface ICanReadAndWrite 
{ 
    string Id 
    { 
     get; 
     set; 
    } 
} 

Aquí está una clase de usarlos:

public class SomeObject : IReadOnly, ICanReadWrite 
{ 
    public string Id 
    { 
     get; 
     set; 
    } 
} 

Tenga en cuenta que la misma propiedad en la clase puede soportar ambas interfaces.

Tenga en cuenta que, según el comentario, la única forma de obtener una solución robusta sería tener también un objeto contenedor.

En otras palabras, esto no es bueno:

public class SomeObject : IReadOnly, ICanReadWrite 
{ 
    public string Id 
    { 
     get; 
     set; 
    } 

    public IReadOnly AsReadOnly() 
    { 
     return this; 
    } 
} 

como la persona que llama simplemente puede hacer esto:

ICanReadWrite rw = obj.AsReadOnly() as ICanReadWrite; 
rw.Id = "123"; 

para conseguir una solución robusta, necesita un objeto envoltorio, como este:

public class SomeObject : IReadOnly, ICanReadWrite 
{ 
    public string Id 
    { 
     get; 
     set; 
    } 

    public IReadOnly AsReadOnly() 
    { 
     return new ReadOnly(this); 
    } 
} 

public class ReadOnly : IReadOnly 
{ 
    private IReadOnly _WrappedObject; 

    public ReadOnly(IReadOnly wrappedObject) 
    { 
     _WrappedObject = wrappedObject; 
    } 

    public string Id 
    { 
     get { return _WrappedObject.Id; } 
    } 
} 

Esto funcionará, y será robusto, hasta el punto donde la persona que llama utiliza la reflexión.