2010-04-08 29 views
32

¿Es correcto derivar una clase abstracta de una clase no abstracta o hay algún problema con este enfoque?Derivar clase abstracta de la clase no abstracta

tope aquí tienes un pequeño ejemplo:

public class Task { 
    // Some Members 
} 

public abstract class PeriodicalTask : Task { 
    // Represents a base class for task that has to be done periodicaly. 
    // Some additional Members 
} 

public class DailyTask : PeriodicalTask { 
    // Represents a Task that has to be done daily. 
    // Some additional Members 
} 

public class WeeklyTask : PeriodicalTask { 
    // Represents a Task that has to be done weekly. 
    // Some additional Members 
} 

En el ejemplo anterior no quiero hacer el resumen de tareas de clase, porque quiero crear una instancia directamente. PeriodicalTask ​​debe heredar la funcionalidad de Tarea y agregar algunos miembros adicionales, pero no quiero crear una instancia directamente. Solo la clase derivada de PeriodicalTask ​​debe ser instanciada.

Respuesta

49

No veo nada malo en este enfoque.

Es posible que tenga algún tipo básico que se pueda describir en términos concretos. Ahora bien, el hecho de que un objeto de este tipo pueda clasificarse de acuerdo con algún subtipo, no implica que todos estos subtipos sean igualmente concretos; a su vez, pueden requerir una mayor concreción, por así decirlo.

mundo real ejemplo:

Person - concreto (no abstracta)
Sibling: Person - abstracta
Brother: Sibling - concreto
Sister: Sibling - concreto

+2

Ejemplo perfecto Dan –

+0

Buen ejemplo, por lo tanto, aceptado – Jehof

+0

¡Guau! Realmente, buen ejemplo. – ManuelSchneid3r

0

Usar el resumen no es el enfoque correcto aquí, entonces, use un constructor interno o protegido, por ejemplo. Eso evitaría que las instancias de PeriodicalTask ​​se crearan directamente, pero sus clases derivadas todavía tendrían acceso a él.

+0

¿Podría dar más detalles? Sí, un constructor protegido/interno podría evitar que se creen instancias de 'PeriodicalTask'. Pero también requeriría cualquier método/propiedad abstracta de 'Tarea' para tener implementaciones. –

+0

No importa ... Me perdí esa tarea no era abstracta. Ambos enfoques funcionarían igual de bien en esta situación. Aparte de eso, no podría obligar a alguien a implementar un método en una clase derivada. –

+0

@kprobst: Sí, puedo hacerlo, pero luego pierdo la posibilidad de definir miembros abstractos, que deben implementarse por tipos derivados. Los miembros virtuales no son una opción, porque los tipos derivados deben definir cómo funcionan. – Jehof

17

Nada de malo en eso.

Si observa una gran jerarquía como WinForms, encontrará varias capas de tipos abstractos.

Las tareas de MSBuild también son un buen ejemplo (y más relevante).

12

Este tipo de t hing sucede todo el tiempo: todas las clases abstractas heredan de System.Object, una clase que no es abstract por sí mismo.

new System.Object() a veces es útil para el bloqueo, si no tiene nada más alrededor, puede bloquearlo.

+0

Es un buen punto. Este hecho lo eché de menos, porque la herencia de System.Object no debe establecerse explícitamente. – Jehof