2011-11-23 10 views
6

Siempre encuentro confusión con quién debería saber sobre el otro.¿Quién debería saber sobre el otro?

por ejemplo:

Circle.Draw(&canvas) o Canvas.Draw(&circle)

o Draw(&canvas, &circle)

EmployeeVector.Save(&file) o File.Save(&employee_vector)

o incluso todavía

void operator() (Employee e) { Save(e.Serialize();} 
    for_each(employees.begin(), employees.end(),File) 

Creo que termino "abstrayendo" demasiado donde tengo todo tipo de adaptadores, así que nadie sabe de nadie.

Respuesta

8

Depende de quién tenga la experiencia.

Si lo único que puede dibujar son círculos, entonces por supuesto puede ponerlo en Canvas y ponerse en camino. Si Canvas tiene un método para dibujar genéricos Shape s, entonces recae sobre las diversas subclases de Shape para dibujarse. Por ejemplo, un círculo seguramente sabe cómo dibujarse sobre un lienzo. Dudo que un lienzo sepa de forma nativa cómo dibujar un círculo, a menos que codifique la funcionalidad, lo que mata la idea de polimorfismo.

Por las mismas razones, un vector probablemente sabría cómo guardarse en un archivo, pero dudo que un archivo sepa qué hacer con un vector. Pero un vector puede contener una variedad de cosas, por lo que debe delegar la mayor parte del trabajo a sus elementos reales. Entonces, la idea for_each es probablemente la mejor.

+0

¿Qué pasa si el lienzo cambiara? De lo que tendrías que cambiar el código del círculo en lugar de solo el código del lienzo. –

+0

depende si trabajas con una abstracción de un lienzo –

+0

@Joe Tendrás que cambiar el código de todos modos. Si cambia el lienzo, debe modificar un grupo de métodos en 'Canvas', o modificar un método en cada clase de forma.De cualquier manera, tiene más sentido modificar el código relacionado con un círculo en la clase 'Circle' que hacerlo en la clase' Canvas'. Además, ¿por qué cambiaría el lienzo? Su interfaz probablemente tenga que mantener el cambio para evitar interrumpir las llamadas. –

2

Al igual que la mayoría de las preguntas de diseño, la respuesta es, depende. :-)

¿Es significativo que algo sepa dibujarse a sí mismo? posiblemente. También es igualmente posible que otra cosa sepa cómo dibujarlo. Si el objeto es una entidad gráfica, probablemente debería saber dibujarse a sí mismo.

En cuanto a cosas como guardar, de nuevo, depende ... puede ser bueno que las cosas sepan serializar a una abstracción como una secuencia, pero también, a veces, es mejor no unir entidades a triviales cuestiones como la serialización ....

0

Para las clases que estás creando, por lo general haces que hagan un trabajo que las involucre. Un Circle se dibujará en un Canvas, así lo hará un Rectangle. De esta forma, si todas son subclases de Shape, pueden dibujarse a través de una interfaz Shape. Es lo mismo para ahorrar. Esto es extensible: no necesita adivinar todas las formas posibles al diseñar la clase Canvas.

Para los casos "depende", para mí, generalmente implica métodos de utilidad para las clases ya definidas por alguna biblioteca. Por ejemplo, guarde/cargue las estructuras de datos STL comúnmente usadas, como map, set, vector, etc; a través de una clase de utilidad File con métodos static.

Cuestiones relacionadas