2009-03-02 30 views

Respuesta

37

Eso depende, si nunca quiere ser capaz de crear una instancia de la clase base y luego hacerlo abstracto. De lo contrario, déjalo como una clase normal.

+1

Exactamente, si no tiene sentido crear una instancia de la clase base, hágala abstracta. – mbillard

0

Yo diría que si no estás planeando llamar a la clase base por sí mismo, entonces debes definirla como una clase abstracta.

+0

Diría que eso no es suficiente: solo debes declarar un resumen de clase si no tiene sentido crear una instancia directamente. Si planeas o no es un problema completamente diferente. –

0

Depende de si desea que la clase base se implemente por sí misma o no.

Como clase abstracta, no puede crear objetos a partir de ella.

6

Depende, ¿tiene sentido que la clase base en cuestión exista por sí misma sin ser derivada? Si la respuesta es sí, entonces debería ser una clase regular; de lo contrario, debería ser una clase abstracta.

16

Si no se debe crear una instancia de la clase base, conviértala en una clase abstracta; si la clase base debe crearse una instancia, no la haga abstracta.

En este ejemplo, tiene sentido hacer que la clase base abstracta como la clase base no tiene un significado concreto:

abstract class WritingImplement 
{ 
    public abstract void Write(); 
} 

class Pencil : WritingImplement 
{ 
    public override void Write() { } 
} 

Sin embargo, en el siguiente ejemplo se puede ver cómo la clase base tiene un significado concreto :

class Dog 
{ 
    public virtual void Bark() { } 
} 

class GoldenRetriever : Dog 
{ 
    public override void Bark() { } 
} 

todo es bastante subjetiva de verdad - que debería ser capaz de hacer un buen juicio personal basado en las necesidades de su dominio particular.

0

Las clases abstractas son geniales para la funcionalidad predefinida, por ejemplo, cuando se conoce el comportamiento exacto mínimo que una clase debe exponer, pero no los datos que debe usar para hacerlo o la implementación exacta.

abstract class ADataAccess 
{ 
    abstract public void Save(); 
} 

normales (no clases abstractas) puede ser grande para cosas similares, pero usted tiene que conocer los detalles de implementación para poder escribirlos.

public class DataAccess 
{ 
    public void Save() 
    { 
     if (_is_new) 
     { 
      Insert(); 
     } 
     else if (_is_modified) 
     { 
      Update(); 
     } 
    } 
} 

Además, puede utilizar las interfaces (individualmente o en clases, ya sea abstracto o no) para definir el mismo tipo de definición de prototipo.

interface ISaveable 
{ 
    void Save(); 
    void Insert(); 
    void Update(); 
} 

class UserAccount : ISavable 
{ 
    void ISavable.Save() { ... } 
    void ISavable.Insert() { ... } 
    void ISavable.Update() { ... } 
} 

Sin embargo, otra opción podría estar usando genéricos

class GenDataAccess<T> 
{ 
    public void Save() 
    { 
     ... 
    } 
} 

Todos estos métodos se pueden utilizar para definir un cierto prototipo de clases para trabajar con ellos. Formas de asegurarse de que el código A pueda hablar con el código B. Y, por supuesto, puede mezclar y combinar todo lo anterior a su gusto. No hay un camino definido, pero me gusta definir interfaces y clases abstractas, y luego referirme a las interfaces. De esta forma, se eliminan algunos de los requisitos de pensamiento para "fontanería" en clases de nivel superior, manteniendo la máxima flexibilidad. (Tener interfaces elimina el requisito de usar la clase base abstracta, pero lo deja como una opción).

1

Las clases abstractas son para clases parcialmente implementadas.

Por sí mismo no tiene sentido tener una instancia de una clase abstracta, es necesario derivarla. Si desea poder crear la clase base, no puede ser abstracto.

Me gusta pensar en clases abstractas como interfaces que tienen algunos miembros predefinidos ya que son comunes a todas las subclases.

1

parece este un modo diferente

Es mi una clase base un objeto completo por sí mismo?

Si la respuesta es no, entonces hágalo abstracto. Si es sí, entonces probablemente quieras convertirlo en una clase concreta.

3

sugiero:

  • Hacer una interfaz.
  • Implemente la interfaz en su clase base.
  • Haga que la clase base sea una clase real, no abstracta (consulte a continuación por qué).

La razón por la que prefiero clases reales en lugar de las clases abstractas es que las clases abstractas no se pueden crear instancias, lo que limita las opciones futuras innecesariamente. Por ejemplo, más adelante puedo necesitar el estado y los métodos proporcionados por la clase base pero no puedo heredar y no necesito implementar la interfaz; si la clase base es abstracta, no tengo suerte, pero si la clase base es una clase regular, entonces puedo crear una instancia de la clase base y mantenerla como un componente de mi otra clase, y delegar en la instancia para reutilizar el estado/métodos proporcionados.

Sí, esto no sucede a menudo, pero el punto es: hacer que la clase base abstracta evite este tipo de reutilización/solución, cuando no hay ninguna razón para hacerlo.

Ahora, si una instancia de la clase base de alguna manera ser peligroso, a continuación, hacer que sea abstracto - o, preferiblemente, que sea menos peligroso, si es posible ;-)

3

Piense en ello como una cuenta bancaria:

Usted puede hacer una cuenta base abstracta genérica llamada "Cuenta", que contiene información básica, como detalles del cliente.

Luego puede crear dos clases derivadas llamadas "Cuenta de ahorro" o "Cuenta de débito" que pueden tener su propio comportamiento específico mientras se benefician del comportamiento de la clase base.

Esta es una situación donde el cliente debe tener una Cuenta de ahorros o una Cuenta de débito, una "Cuenta" genérica no está permitida, ya que no es muy popular en el mundo real tener una cuenta sin descripción.

Si puede crear un escenario similar para sus necesidades, el resumen es el camino a seguir.

-8

Creo que muchos de ustedes deberían volver a las clases OO básicas.

El principio subyacente básico en OOA/OOD es abstraer resumen abstracto, hasta que no pueda abstraerse más. Si lo que estás mirando es una abstracción, entonces que así sea, eso es lo que tu OOA/OOD ya te dijo.Sin embargo, si está sentado preguntándose si el "código" debe ser abstracto o no, obviamente no sabe lo que significa el término y debe volver a aprender OOA/OOD/OOP básico :-)

Más al punto que debería aprende patrones de diseño y teoría armónica, ¡esto te ayudará inmensamente con tus diseños OO!

+8

Te puedo decir que lees mucho. Gaste parte de esa energía en lugar de aprender a escribir sin ser ofensivo. –

Cuestiones relacionadas