Diseño de Software
Primero diseña, luego codifica
Principios SOLID
Los principios SOLID son guías para el desarrollo de software con la intención de crear un software de calidad, aplicando buenas prácticas para eliminar malos diseños que llevan a un software caótico, difícil de mantener.
Single Responsibility
arrow_forwardUna clase debe tener una, y solo una, razón para cambiar; o sea, encapsular la responsabilidad.
Open Closed
arrow_forwardLas entidades de software deben estar abiertas para su extensión y cerradas para su modificación.
Liskov Substitution
arrow_forwardLos objetos de una subclase deberían ser reemplazables con objetos de sus subclases.
Interface Segregation
arrow_forwardNingún cliente debería verse forzado a depender de métodos que no utiliza.
Dependency Inversion
arrow_forwardLos módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.
Patrones de Diseño
Representan soluciones a problemas comunes, aplicables a diferentes problemas de diseño en distintas circunstancias. Se categorizan según su propósito: Creacionales, Estructurales y de Comportamiento.
Creacionales
Definen la manera de crear un objeto. Abstraen los detalles de la creación, ayuda a crear un sistema independiente de cómo se crean, se componen y se representan los objetos.
Abstract Factory
arrow_forwardDefine una interfaz para crear una familia de objetos relacionados sin especificar su clase.
Builder
arrow_forwardSepara la construcción de un objeto complejo de su representación.
Factory Method
arrow_forwardDefine una interfaz para crear un objeto, pero deja que las subclases decidan qué clase instanciar.
Prototype
arrow_forwardPermite la creación de nuevos objetos clonando un objeto existente conocido como el prototipo.
Singleton
arrow_forwardGarantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global.
Estructurales
Se centran en la forma de combinar las clases y los objetos para formar estructuras más grandes, y así poder resolver problemas complejos.
Adapter
arrow_forwardConvierte la interfaz de una clase en otra que esperan los clientes.
Bridge
arrow_forwardDesacopla una abstracción de su implementación, de manera que ambas puedan variar.
Composite
arrow_forwardCompone objetos en estructuras de árbol para representar jerarquías de parte-todo.
Decorator
arrow_forwardAgrega responsabilidades adicionales a un objeto de manera dinámica.
Facade
arrow_forwardProporciona una interfaz unificada y simplificada a un conjunto de interfaces en un subsistema.
Flyweight
arrow_forwardUsa el compartido para dar soporte a un gran número de objetos de grano fino de forma eficiente.
Proxy
arrow_forwardBrinda un sustituto para controlar el acceso, posponer su creación o gestionar accesos remotos.
Comportamiento
Tienen que ver con algoritmos y con la asignación de responsabilidades a objetos.
Chain of Responsibility
arrow_forwardDesacopla al emisor de una solicitud de su receptor.
Command
arrow_forwardEncapsula una petición en un objeto.
Interpreter
arrow_forwardEvalúa sentencias en un lenguaje.
Iterator
arrow_forwardAccede a elementos secuencialmente.
Mediator
arrow_forwardReduce complejidad de comunicaciones.
Memento
arrow_forwardCaptura y restaura estados internos.
Observer
arrow_forwardSuscripción para cambios de estado.
State
arrow_forwardAltera comportamiento según estado.
Strategy
arrow_forwardAlgoritmos intercambiables.
Template Method
arrow_forwardEsqueleto de algoritmo delegable.
Visitor
arrow_forwardNuevas operaciones sin cambios.
Deep Dive: El costo del mal diseño
A menudo escuchamos que el diseño de software es un "lujo" que los equipos de ritmo rápido no pueden permitirnos. Sin embargo, la realidad técnica demuestra lo contrario a través de la metáfora de la deuda técnica.
"Si no tienes tiempo para hacerlo bien, ¿cuándo tendrás tiempo para hacerlo de nuevo?"
Un sistema mal diseñado presenta lo que llamamos rigidez. Intentar cambiar una parte del sistema rompe otras tres partes no relacionadas. Esta fragilidad detiene la innovación y convierte el mantenimiento en una pesadilla de "monkey patching".
Al aplicar patrones de diseño, no estamos añadiendo complejidad; estamos aplicando soluciones probadas a problemas recurrentes. Estamos creando un lenguaje común para el equipo y asegurando la escalabilidad del producto a largo plazo.
Explorar otros temas
Siguiente nivel:
Clean Architecture arrow_forward
Diseñar es comenzar a codificar con un plan (en lugar de comenzar escribiendo código).
Software robusto, con buenos atributos de calidad y preparado para el futuro.