design - segregation - Criterios de diseño
solid principles c# (13)
Básicamente me salgo con la programación de interfaces. Intento encapsular lo que cambia a través de los casos para evitar la duplicación de código y aislar el código en fragmentos manejables (para mi cerebro). Más tarde, si lo necesito, puedo refactorizar el código con bastante facilidad.
¿Qué principios generalmente sigues cuando haces diseño de clase?
Como se mencionó anteriormente, algunos de los principios fundamentales de Diseño Orientado a Objetos son OCP, LSP, DIP e ISP.
Una excelente descripción de estos por Robert C. Martin (de Object Mentor) está disponible aquí: Principios y patrones OOD
Consulte http://www.objectmentor.com/resources/publishedArticles.html
Esta es una buena referencia para los principios de diseño en general.
El paradigma " Adquisición de recursos es inicialización " es útil, especialmente cuando se escribe en C ++ y se trata de recursos del sistema operativo (manejadores de archivos, puertos, etc.).
Un beneficio clave de este enfoque es que un objeto, una vez creado, es "completo", no hay necesidad de inicialización en dos fases y no hay posibilidad de objetos parcialmente inicializados.
El patrón de diseño más fundamental debe ser KISS (mantenerlo simple estúpido) Lo que significa que a veces no se utilizan clases para algunos elementos en absoluto es la solución correcta.
Eso y tarjetas CRC (Clase, Responsabilidad, Colaboradores) (escriba la tarjeta en sus archivos de encabezado, no en las cartas reales de esa manera, porque también es fácil de entender la documentación)
Los principios SÓLIDOS .
O al menos, trato de no alejarme demasiado de ellos.
Los principios SÓLIDOS y el patrón de Liskov, junto con el patrón de responsabilidad única.
Por lo general, intento adaptar la clase a uno de los patrones de diseño de oo .
débilmente acoplado, altamente cohesionado.
Composición sobre la herencia.
Principios de Diseño de Clase Orientado a Objetos (los principios "SÓLIDOS")
- SRP: El Principio de Responsabilidad Individual Una clase debe tener una, y solo una, razón para cambiar.
- OCP: El Principio Abierto Cerrado. Usted debería poder extender el comportamiento de una clase, sin modificarla.
- LSP: El principio de sustitución de Liskov Las clases derivadas deben ser sustituibles por sus clases base.
- ISP: el principio de segregación de la interfaz Haga interfaces de grano fino que sean específicas del cliente.
- DIP: El Principio de Inversión de Dependencia depende de abstracciones, no de concreciones.
Fuente: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
El Diseño Dirigido por Dominio es generalmente un buen principio a seguir.
No olvides la Ley de Demeter .
Una cosa que me gustaría añadir a todo esto es la creación de capas, Definir capas en su aplicación, la responsabilidad general de una capa, forma en que interactúen dos capas. Solo las clases que tienen la misma responsabilidad que la de la capa deberían permitirse en esa capa. Hacer esto resuelve un montón de caos, garantiza que las excepciones se manejen de manera adecuada y garantiza que los nuevos desarrolladores sepan dónde colocar su código.
Otra forma de diseñarlo es diseñando su clase para que sea configurable creando un mecanismo donde la configuración pueda ser conectada a su clase, en lugar de reemplazar los métodos en sub clases, identificar qué cambios, ver si pueden configurarse y asegurar que esta funcionalidad sea derivado de configuraciones