vb.net - una - ¿Debería esta propiedad ser parte de la interfaz de mi objeto?

new no se puede usar en una interfaz

Question

Tengo una propiedad llamada "IsSecureConnection" que es parte de la interfaz de mi objeto. Esto tiene sentido para la mayoría de las implementaciones de la interfaz, sin embargo, en algunas implementaciones quisiera hacer la propiedad ReadOnly.

¿Debería omitir esta propiedad de la interfaz del objeto a pesar de que todas las implementaciones lo requieren (aunque ligeramente diferente en ocasiones)?

¡Gracias!

Answer 1

Las interfaces son como la sal: espárcelas en todas partes:

public interface ICanBeSecure
{
bool IsSecureConnection { get; }
}
public interface IIsSecureable : ICanBeSecure
{
bool IsSecureConnection { get; set;}
}

Answer 2

Necesitas evaluar el caso. Si no tiene sentido que sea siempre escribible, sepárelo en una segunda interfaz.

public interface IFoo {
bool SecuredConnection{ get; }
}
public interface ISecurableOptionFoo: IFoo {
bool SecuredConnection{ get; set; }
}

Answer 3

Realmente depende de lo que sea más legible para sus clientes. Puedo pensar en un par de opciones:

1) La interfaz heredada, aunque no me gusta esconderme, y creo que es un poco feo para cualquier VB.NET o clientes explícitos implementar:

interface IObject {
bool IsSecureConnection { get; }
// ... other interface definitions //
}
interface ISecurableObject : IObject {
new bool IsSecureConnection { get; set; }
}

2) Divida el conjunto de la propiedad, con una interfaz heredada:

interface IObject {
bool IsSecureConnection { get; }
// ... other interface definitions //
}
interface ISecurableObject : IObject {
void SetConnectionSecurity(bool isSecure);
}

3) Cambiar la semántica para tratar de adquirir una conexión segura, que un implementador puede devolver de forma gratuita desde:

interface ISecurable {
bool IsSecureConnection { get; }
bool TrySecureConnection();
}

4) Agregue una propiedad de verificación adicional:

interface ISecurable {
bool IsSecureConnection { get; set; }
bool SupportsSecureConnection { get; }
}

Todos estos son, IMO, diseños válidos para ciertos contextos. Dado que no tengo información sobre los casos de uso, salvo que casi siempre se puede establecer una conexión segura, probablemente votaría por 3. Es fácil de implementar, solo hay 1 ruta de código para los clientes, y hay ningún mecanismo de excepción (que es otra forma de acoplamiento). Usted tiene el peligro de que los clientes no verifiquen el retorno de TrySecureConnection, pero creo que tiene menos problemas que las otras opciones.

Si los clientes prefieren una conexión segura, pero no requieren una, entonces 1 tiene la desventaja de requerir sobrecargas o que el cliente compruebe si su IObject es realmente un Objeto inexacto. Ambos son feos. 2 tiene el mismo problema, pero sin el truco de las nuevas / sombras problemáticas. Sin embargo, si algunos clientes requieren una conexión segura, entonces este (o 2) es probablemente el camino a seguir, de lo contrario, no puede usar la seguridad de tipo para aplicar una conexión asegurable.

4, mientras que un diseño válido de IMO (algunos estarían en desacuerdo, ver reacciones a IO.Stream) es fácil para los clientes equivocarse. Si el 90% de los implementadores son asegurables, es fácil no verificar la conexión segura de Supports. También existe la opción de un implementador de lanzar una excepción o descartar la llamada IsSecureConnection = true si no es compatible, lo que exige que los clientes capturen y verifiquen el nuevo valor de IsSecureConnection.

Answer 4

Solo agrega el getter en la interfaz.

public interface Foo{
bool MyMinimallyReadOnlyPropertyThatCanAlsoBeReadWrite {get;}
}

Las interfaces especifican el mínimo que un objeto debe implementar; no dice lo que un objeto no puede hacer. Para eso, debe considerar la creación de clases base.