La interfaz no debe tener propiedades?

Question

Mi colega de la oficina me dijo hoy que es una mala práctica usar propiedades en las interfaces. Él rojo que en algunos artículos de MSDN, que no pude encontrar (bueno, yo estaba tratando de googlear algunas veces, probablemente con palabras clave incorrectas). También me dijo que solo los métodos deberían estar en la interfaz. Ahora, soy consciente de que no se trata de una regla estricta, ya que obviamente en .net puede hacer la firma de la propiedad en la interfaz y compilarla.

¿Pero es cierto que es una mala práctica/diseño/oop? ¿Y por qué?

Señalar a la derecha literatura o recurso web sería útil también.

Gracias

Answer 1

Voy a agregar mi voz aquí también - Nunca he encontrado esta recomendación. Una propiedad es efectivamente un par de métodos get/set.

Como cualquier otra decisión de diseño. Si realmente tiene sentido; si es apropiado para el sistema en diseño, si no causa problemas de mantenimiento, si no causa problemas de rendimiento, no debería haber ninguna razón por la que no pueda hacerlo.

Answer 2

que nunca se han encontrado con cualquier persona que hace esta afirmación, ni veo ninguna buena razón para ello. El .NET Framework está lleno de interfaces con propiedades.

Answer 3

Una interfaz es un contrato para una clase para implementar y no veo ninguna razón por la cual las propiedades se deben excluir de dicho contrato. Además, las propiedades son intrínsecas a .NET.

Como ejemplo: ICollection<T> tiene Count y IsReadOnly.

Answer 4

Nunca he visto algo como esto per se, pero hace un tiempo se habló de no usar propiedades en las definiciones de interfaz multiplataforma, ya que hay muchas plataformas que no admiten propiedades, pero casi todo admite métodos.

Answer 5

No se me ocurre ninguna documentación que respalde esa premisa. Además, puedo pensar en muchos ejemplos en el BCL que hacen todo lo contrario. Eche un vistazo a casi todas las interfaces de colección y verá las propiedades.

Answer 6

Prácticamente, una propiedad tiene dos funciones: una para obtener el valor y otra para establecer el valor. Aunque las propiedades son "características" de primera clase de C#, esto sigue siendo cierto.

¿Por qué no se permiten las propiedades en las interfaces?

Answer 7

No veo ninguna razón para no tener Propiedades como parte de su Interfaz. ¿De qué otro modo implementarías el acceso a los miembros de datos? Obtenga métodos y establezca métodos en lugar de propiedades. Eso sería simplemente feo y tan 1990's.

Answer 8

Existe un término ampliamente reconocido "olor a código". Sugiero introducir el concepto de "olor a programador", si alguien insiste en alguna regla, pero no puede explicar por qué, es un olor. Su colega debería ser capaz de explicar por qué las propiedades en la interfaz son malas. Si no puede, probablemente esté equivocado incluso si el artículo al que se refiere es correcto.

Ese artículo puede estar hablando de algunos tipos específicos de interfaces, puede tener algo que ver con COM e interoperabilidad o lo que sea. O puede que lo haya entendido mal. Comprender las reglas y ser capaz de explicarlas es parte importante del uso de las reglas.

Answer 9

La única desventaja que puedo ver en propiedades versus métodos es que no hay problema en tener una interfaz con un método get, una interfaz con un método set y una interfaz que combine los dos (un escenario que permita un máximo flexibilidad con covarianza y contravarianza), las propiedades no se combinan muy bien. No estoy seguro de por qué una propiedad de lectura y escritura no se considera simplemente igual que una propiedad de lectura y escritura, pero no lo es. Si una interfaz admite una propiedad de solo lectura y una propiedad de solo escritura del mismo nombre, cualquier intento de acceder a las propiedades a través de la interfaz combinada fallará en función de la ambigüedad reclamada.

Answer 10

Es un mal diseño ya que se contamina el espacio variable de la implementación que se utiliza para almacenar el estado con variables que se usaron como parte del contrato de clase.

Answer 11

La única forma en que puedo pensar, por qué las propiedades son malas para las interfaces, cuando defines interfaces para servicios (como WCF, WebServices, Remoting) alojadas en diferentes máquinas o dominios de aplicación.

Las propiedades de causa implican que son rápidas (también conocido como obtención y configuración de valores) que no es cierto para los servicios, debido a la actividad de red y serialización. Un método de explotación para obtener o establecer valores en las interfaces de servicio implica que podría tomar algún tiempo completar la operación.

Answer 12

IEnumerator es un ejemplo perfecto para el escenario donde necesitará propiedad como miembro de la interfaz. ¿Cómo va a almacenar el elemento actual si no aplica el implementador para hacerlo?