Separación de la preocupación / Principio de responsabilidad única

7

Acabo de leer los principios de SOLID, y este es uno de los problemas que tengo al diseñar software. Soy relativamente nuevo (4 meses profesionalmente) en codificación.

La idea es simplemente encapsular las clases en aquellas que realizan una sola tarea.

Por ejemplo, qué pasa si tiene una clase que crea y completa una vista de árbol y la configura según sus especificaciones. Luego, desea que los datos se recuperen de una base de datos cuando el usuario hace clic en los nodos. ¿Dirías que esto es dos preocupaciones separadas?

  1. Rellene y configure la vista de árbol
  2. ¿Obtener datos de la base de datos?

También, en la misma aplicación. Tiene una vista de datos que también se rellena con datos dinámicos. Por lo tanto, ¿pondría esa recuperación de datos en la misma clase que la recuperación de datos de vista en árbol o sería otra clase completamente separada?

Gracias.

    
pregunta Darren Young 21.01.2011 - 09:34

5 respuestas

7

Separación de preocupaciones

Cada objeto hace su propio trabajo. Por lo tanto, en su ejemplo, la vista de árbol solo sabe acerca de ser una vista de árbol (presumiblemente mostrando datos). Puede cargar sus propios datos pero no debe saber de dónde provienen los datos. Si sabe de dónde provienen los datos, entonces está estrechamente relacionado con la fuente de datos (es decir, puede ser un DB ahora, pero ¿qué sucede en la versión 2 cuando necesita obtener datos del transbordador espacial?).

En su lugar, debe pasar a la vista de árbol una interfaz (que sepa cómo usar) para recuperar sus datos de:

// Example
class DataRetrieveInterface
{
     // STUFF
     virtual std::string getItemAt(int index)  = 0;
};
class DBDataRetriever:      public DataRetrieveInterface {};
class ShuttleDataRetriever: public DataRetrieveInterface {};
class MockDataRetriever:    public DataRetrieveInterface { /* Needed for testing */ }

class TreeView
{
    public:
        TreeView(DataRetrieveInterface& data)
        {
             // use data to populate the view.
        }
};

Si reutiliza DataRetrieveInterface para la cuadrícula es algo que debe decidir como parte de su diseño. ¿Es suficientemente genérico? Alternativamente, puede derivar de esta interfaz y tener algo más específico de cuadrícula para el objeto de cuadrícula. En este punto, no hay suficiente información en la pregunta para decir si debe o no debe tener una interfaz diferente para la cuadrícula.

    
respondido por el Martin York 21.01.2011 - 09:54
3

Separe la serialización / deserialización de las clases

Personalmente he encontrado que es preferible separar la serialización / deserialización de las clases reales. Si tiene una clase que proporciona datos en algún formato (xml / dataset / json o lo que prefiera) construye / carga la clase. La clase no debe tener dependencias relacionadas con la serialización.

De esa manera, puede cambiar más fácilmente los métodos de serialización, admitir diferentes tipos de datos, etc.

    
respondido por el Homde 21.01.2011 - 10:05
1

La representación de datos y la recuperación de datos son dos preocupaciones independientes, por lo que pertenecen a objetos separados.

Es posible que tenga una situación en la que tenga sentido que una sola clase de recuperación de datos alimente datos a una vista de árbol y una cuadrícula de datos: dos vistas diferentes en los mismos datos. A primera vista parece poco probable: los árboles y las tablas no son terriblemente similares.

    
respondido por el Frank Shearar 21.01.2011 - 09:48
0

Piensa en cómo escribirías una prueba de unidad para esa clase.

¿Qué funcionalidad separada puede y qué probaría? Datos de población, configuración, carga desde la base de datos son preocupaciones separadas. Dividirlos facilita su comprensión, prueba y reutilización.

    
respondido por el LennyProgrammers 21.01.2011 - 10:01
0

Posiblemente, le resultará más fácil pensar en ello menos como una cuestión teórica y más como algo práctico.

Imagina que estás escribiendo dos aplicaciones que proporcionarán una funcionalidad idéntica pero a través de dos front-end completamente diferentes: un cliente web, un cliente de escritorio nativo (suponiendo que ambos están escritos en el mismo idioma).

Ahora, diseñe y codifique de tal manera que tenga la menor duplicación que sea prácticamente posible.

En términos de separar la recuperación de datos (en realidad obtener los datos) y la lógica de negocios (aplicar el procesamiento y la lógica a esos datos), haga lo mismo pero ahora suponiendo que tendrá que implementar la misma solución tanto para SQL Server como para datos Almacenamiento utilizando archivos planos XML.

Nuevamente, diseñe y codifique de tal manera que tenga la menor duplicación que sea prácticamente posible.

    
respondido por el Jon Hopkins 21.01.2011 - 11:14

Lea otras preguntas en las etiquetas