¿Tiene un mal diseño de la clase base vacía?

Necesito una clase base para mis clases de DTO que se utilizarán en mis interfaces genéricas.¿Tiene un mal diseño de la clase base vacía?

Pero las clases de DTO no tienen nada en común. Son solo clases tontas que contienen algunas propiedades.

public void GetGridData() 
{ 

    IDataForGrid<DTOBase> aa; 

    if(request == 1) aa = new CustomerGridData; 
    if(request == 2) aa = new OrderGridData; 

    var coll = aa.GetList(); 
} 

public class CustomerGridData : IDataForGrid<CustomerDTO> 
{ 
    ... 
}

Fuente

2010-03-11 user137348

El objeto es una clase base vacía :) –

+11

@Brian - El objeto no está vacío :) –

esto se relaciona con http://stackoverflow.com/questions/2424099/generic-interface-problem para el fondo –

Si tienen nada en común, ¿qué vas a hacer con los casos que se recuperan de su lista?

En cualquier caso, tener la clase de base significa que cuando (bueno, si ) a identificar algo que hacen necesidad de tener en común más adelante, usted no tiene que volver atrás y refactor (re- base) todo. Pero en cualquier caso, consideraría utilizar una interfaz en lugar de una clase base para este tipo de cosas, ya que no parece que haya una gran necesidad de reutilizar la implementación subyacente (¡ya que no tienen nada en común todavía!). Dependerá de lo que creas que puedan tener en común más adelante.

Fuente

2010-03-11 10:54:09

No es un mal diseño, aunque algo poco común. Piénsalo de esta manera - hay por lo menos dos beneficios, mientras que no hay inconvenientes:

La clase base sirve como un filtro para sus interfaces de modo que no se puede pasar cualquier objeto a ellas - sólo su DTO objetos. Las interfaces de marcador también podrían hacerlo.
Cuando finalmente tengan algo en común, será fácil agregarlo allí y no tendrá que refaccionarlo todo.

Fuente

2010-03-11 10:57:08

Las pautas de codificación de .NET dicen que tener una clase base o interfaz vacía (también llamada interfaz de "etiqueta") es un mal estilo. El estilo preferido es usar un atributo en lugar de anotar clases del mismo tipo. También hay un FxCop rule para hacer cumplir esta convención.

Sin embargo, algunas veces (en casos excepcionales) uso este modismo cuando una clase base común es útil para denotar una jerarquía común incluso si no existe una funcionalidad común. Los atributos no se pueden usar para esto.

Por ejemplo, en un intérprete para un lenguaje de programación, varios métodos devuelven una clase base especial Value, es decir, algo que tiene un valor dentro de ese lenguaje de programación. Básicamente, este valor puede ser todo de un número a una cadena (que, son clases especiales, no System.Int32 o System.String) a un objeto compuesto. I podría también devolver System.Object pero esto haría que el tipeo de mi interfaz pública sea más débil.

Buen código de auto-documentación se beneficia de la interfaz restringida.

Fuente

2010-03-11 10:58:00

Una interfaz/clase de marcador puede servir como una restricción de tiempo de compilación para que no pueda pasar el objeto incorrecto a un método. Los atributos no pueden hacer esto. Entonces me inclino a estar en desacuerdo con la directriz. –

¡Estaba a punto de publicar este enlace! http://msdn.microsoft.com/en-us/library/ms182128%28VS.80%29.aspx –

@Vilx: como soy yo (ver el ejemplo que agregué). Pero * es * una guía FxCop. –

En java esto se llama Tag Interface. El enlace proporciona algunos buenos antecedentes sobre las interfaces de etiquetas, sus usos y problemas.

Fuente

2010-03-11 11:00:02

¿Tiene un mal diseño de la clase base vacía?

Respuesta

Cuestiones relacionadas