¿Debería un método de interfaz devolver un objeto personalizado?

Question

Se formuló una pregunta en una discusión que tuve sobre si un método de interfaz debería devolver un objeto personalizado frente a un tipo primitivo.

p. Ej.

public interface IFoo 
{ 
     bool SomeMethod(); 
} 

vs

public interface IFoo 
{ 
    MyFooObj SomeMethod(); 
} 

Dónde MyFooObj es:

public class MyFooObj 
{ 
    bool SomeProp{get;set;} 
} 

El argumento es que usted puede agregar fácilmente las propiedades del objeto en el futuro sin necesidad de cambiar el contrato interfaz.

No estoy seguro de cuáles son las pautas estándar sobre esto?

Answer 1

mi humilde opinión Cambio de la MyFooObj es lo mismo que cambiar/añadir métodos a la interfaz IFoo - por lo que no, no creo que sea una buena idea añadir simplemente otra abstracción - recuerda YAGNI

Answer 2

Mi respuesta estándar es - YAGNI.

Siempre puede cambiar las cosas si resulta de esa manera, en particular si controla el origen completo de la aplicación y cómo se utiliza la interfaz.

Envolver un booleano solo para pronosticar el futuro solo está agregando complicaciones y capas adicionales de abstracción cuando no se necesitan actualmente.

Si está utilizando DDD y técnicas de modelado específicas en su base de código, puede tener sentido tener tales alias a booleanos, si son significativos en su dominio (pero no puedo ver que este sea el caso de un solo booleano valor).

Answer 3

Eso depende un poco de lo que te gusta. Mi opinión, que, en su caso de la muestra, que se pegaba con el simple bool en la definición de interfaz por esas razones:

• es el más sencillo de leer posibilidad
• nadie mira por métodos que no están disponibles

En mi humilde opinión, un objeto tiene sentido solo cuando se requiere una cierta cantidad de complejidad/agrupamiento como resultado.

Answer 4

No veo el objetivo de encapsular tipos primitivos en un objeto personalizado.

Si cambia la definición de este objeto personalizado, entonces realmente cambia el contrato porque la función no devuelve lo mismo.

Creo que es nuevamente un "patrón" sobre-diseñado.

Answer 5

No hay directrices generales sobre esto.

Como se señaló, si usted tiene la semántica de todo el tipo de retorno que piensacreen firmemente pueden cambiar o pueden necesitar ser actualizado en el futuro puede ser mejor para devolver el tipo complejo.

Pero la realidad es que en la mayoría de las circunstancias es mejor mantener las cosas simples y devolver el tipo primitivo.

Answer 6

Si no es necesario para empezar, no debe envolverlo cambiando lo que se devuelve dentro del objeto es simplemente lo mismo que cambiar la interfaz que rompe la regla número uno de la programación con interfaces.

Está a la altura con diseño para la extensión, YAGNI (no lo va a necesitar).

Como nota al margen, me regañaron por cosas como esta al principio de mi carrera.

Answer 7

Si alguna vez necesita devolver algo más que un booleano, es muy probable que también modifique otras partes de la interfaz. No hagas las cosas más complejas de lo que deben ser: la simplicidad es un requisito previo de fiabilidad.

Answer 8

Solo mencioné que si MyFooObj está en un ensamblado que tiene un nombre fuerte, lo actualizas, su versión se actualiza: los clientes antiguos se romperán inmediatamente (por ejemplo, InvalidCastException) debido a una discrepancia de versión (no lo hará). intentar un enlace parcial debido a un nombre fuerte) a menos que recompilen con la nueva versión. Aún has cambiado el contrato de interfaz. Así que lo mejor es mantener las cosas simples, devolver el tipo de primitiva y declarar su cambio de contrato de manera más explícita.

Answer 9

Además de las otras respuestas, agregar un nuevo campo a una clase personalizada es técnicamente todavía un posible cambio radical para los consumidores de la interfaz. Link