2011-03-04 7 views
5

No soy un experto en OOPS o patrones de diseño.¿Hay un automóvil con una pegatina de parachoques en la subclase de un automóvil?

Me he encontrado con esta situación: ¿Es un automóvil con una pegatina de parachoques subclase de un automóvil?

Si no, ¿cómo puedo agregar propiedades dinámicas a la instancia de un objeto? Por ejemplo, un automóvil, un automóvil con una pegatina para el parachoques, etc.

No todos los automóviles vienen con una pegatina para el parachoques. Uno puede agregar una pegatina para el parachoques e incluso más de una pegatina para el parachoques. No puedo implementar una pegatina con el auto, afaik, implementarme me obligará a agregar pegatinas. Una pegatina para el parachoques en un automóvil es una propiedad nueva que surgió después de que se creó el automóvil (¿objeto?).

+0

Depende de su opinión sobre las pegatinas para el parachoques. Sería un dolor tener que hacer una subclase para cada variación de minutos en autos (spoilers, neumáticos para la nieve, antenas). La pregunta no es realmente respondible. –

+1

No, un automóvil con una pegatina sigue siendo un automóvil, tal vez uno de sus atributos haya cambiado, pero no es una subclase, diría yo. –

+3

Responda las siguientes preguntas: ¿Puede cada automóvil tener una pegatina para el parachoques? ¿Cómo se diferencia el comportamiento de un auto con pegatina para parachoques del comportamiento de un automóvil sin uno? ¿Qué cambio de comportamiento se espera si un automóvil tiene varios de ellos? – Philipp

Respuesta

7

Puede usar el Decorator Design Pattern para casos como este. Le permitirá "agregar propiedades dinámicas a la instancia de un objeto", que es lo que mencionó, puede agregar cualquier cantidad de calcomanías o cualquier otra propiedad, en todas las combinaciones posibles "decorando" su clase car.

+0

gracias :) Voy a pasar algún tiempo con el ejemplo del café – Kumar

1

Si la pegatina del parachoques es una cosa común en su caso, puede establecer un atributo booleano (verdadero/falso) o una cadena si eso es todo en su caso.

Si la pegatina del parachoques es complicada para ser una clase de autoservicio, ¿quizás el auto debería implementar la pegatina? (Me refiero a la implementación en Java aquí)

En cuanto a Dynamic, ¿sería aceptable una tabla de propiedades de la base de datos relacionada con el automóvil?

+0

Creo que la clave es, como la anterior, ¿la pegatina para parachoques es lo suficientemente compleja como para requerir una clase propia? ¿Estás grabando que existe una pegatina o los detalles de ella? De lo contrario sólo tienen un valor lógico 0 o más pegatinas, número entero para un conteo, etc. – Karl

+0

esto suele conducir a un buen diseño, pegatina para el parachoques es totalmente opcional, pero se puede tener en un coche o incluso en bicicleta, si es lo suficientemente pequeño como puede – Kumar

0

En realidad, cuando compra un automóvil, elige el automóvil y un conjunto de opciones (música, interior, etc.). Como en la vida real, puedes introducir 'opciones' en tu clase de automóvil. En un caso sencillo se ve como (C++):

class Car { 

    enum CarOptions { 
     Bumper, 
     ... 
    }; 

    ... 

    int options() const { return m_options; } 
    void setOptions(int options) { m_options = options } 

    ... 
}; 

Car c; 
c.setOptions(c.options() | Car::Bumper); 

Por supuesto, esta solución tiene sus pros y contras propios, como cualquier otro.

+0

enumeras pros y contras? – Kumar

+0

pro: Simple; con: solo una indicación booleana de que se ha configurado una opción, no se puede almacenar otra información (como la que está impresa en la etiqueta) – Tony

+0

Ventajas: es muy fácil de usar y es útil cuando tienes muchas opciones (no 1 o 2 pero 10 o 20). Contras: si Bumper es complicado, probablemente debería usar otra solución. Entonces eso depende. – maverik

1

No complique demasiado esto.

class Car 
{ 
public: 
    bool hasBumperSticker() const { return m_hasBumperSticker; } 

private: 
    bool m_hasBumperSticker; 
}; 

O, si la calcomanía tiene sus propias propiedades:

class Car 
{ 
public: 
    bool hasBumperSticker() const { return m_bumperSticker != 0; } 

private: 
    BumperSticker* m_hasBumperSticker; 
}; 
+0

pegatina es un ejemplo, puedo agregar muchas otras propiedades, por lo que de acuerdo con usted, que tendrá que tener un método hasProprtyXYZ() para todas esas propiedades, aquí está algo que sólo me pegó 'code' coche de clase { \t propertyarray privado; \t hasProperty pública (propertyname) {return (isset (this.proprtyarray [propertyname]) verdadera:? False);} \t setProperty pública (propertyname, valor) {this.proprtyarray [propertyname] = valor;}} ' código ' – Kumar

2

Los cambios en los coches que estamos hablando son atributos dinámicos. Personalmente, implementaría una colección de accesorios en la clase Car, uno de los cuales sería un BumperSticker.

Luego puede agregar y quitar Accesorios sin tener que subclase Automóvil para todas las opciones disponibles.

Si recorre la ruta de herencia, piense en la situación cuando un automóvil tiene un BumperSticker y Spoilers, tendría una herencia múltiple que está mal vista en C++ y no está disponible en otros idiomas.

+0

También está mal visto * lógicamente * en este caso, porque un automóvil con pegatinas y un auto con spoilers no son dos tipos diferentes de automóviles. Son atributos de un auto de un solo tipo. –

+0

exactamente, una calcomanía es sólo "otro" atributo o propiedad de un coche que su coche puede tener y la mía puede carecer – Kumar

Cuestiones relacionadas