Cómo usar esta parte¶
En las partes anteriores se construyeron los fundamentos del paradigma orientado a objetos, las relaciones entre objetos, la sintaxis de clases en Java y la herencia con polimorfismo (Fundamentos de la Programación Orientada a Objetos, Encapsulamiento y Relaciones entre Objetos, Herencia y Polimorfismo Conceptual y Herencia y Polimorfismo en Java).
Esta parte cambia el foco: ya no alcanza con que el programa “funcione”. Ahora importa que el diseño sea mantenible, testeable, extensible y robusto frente al cambio.
Orden sugerido de lectura¶
| Orden | Capítulo | Rol en la progresión |
|---|---|---|
| 1 | Refactoring y Code Smells | Instala vocabulario de diagnóstico y mejora segura |
| 2 | SOLID | Agrega criterios para evaluar cohesión, acoplamiento y extensibilidad |
| 3 | Testing OOP | Lleva la verificación desde métodos aislados a colaboraciones y jerarquías |
| 4 | Anti-patrones y Code Smells | Funciona como contraste y catálogo de errores frecuentes |
| 5 | Diseño por Contratos | Cierra la parte formalizando responsabilidades y reglas de sustitución |
Capítulos nucleares¶
Estos capítulos conviene trabajarlos en secuencia, porque arman el hilo principal de la parte:
| Capítulo | Por qué es nuclear |
|---|---|
| Refactoring y Code Smells | Define el vocabulario para detectar problemas y priorizar mejoras |
| SOLID | Da criterios de diseño para justificar refactorizaciones y evaluar decisiones |
| Testing OOP | Aporta la red de seguridad necesaria para cambiar diseño sin romper comportamiento |
Repaso y ampliación¶
Estos capítulos funcionan mejor como contraste, consolidación o cierre formal del recorrido:
| Capítulo | Tipo | Uso sugerido |
|---|---|---|
| Anti-patrones y Code Smells | Contraste y diagnóstico | Leer después de refactoring y SOLID para reconocer decisiones de diseño pobres |
| Diseño por Contratos | Formalización y cierre | Usar para cerrar la parte conectando Liskov, testing y robustez contractual |
Ejes conceptuales¶
Calidad interna del diseño¶
Un sistema puede compilar, pasar tests e igual estar mal diseñado. En esta parte se trabajan criterios para reconocer cuándo un diseño se vuelve rígido, frágil o difícil de extender.
Cambio seguro¶
Refactorizar sin romper comportamiento exige una combinación de criterio de diseño y red de seguridad. Por eso esta parte articula constantemente refactoring, testing y contratos.
Detección temprana de problemas¶
Los anti-patrones y code smells no son errores de sintaxis: son señales de deuda técnica, complejidad innecesaria o mala distribución de responsabilidades.
Conexiones con otras partes¶
Parte 2 aporta las bases conceptuales: objetos, encapsulamiento, jerarquías, clases abstractas e interfaces.
Reglas y Convenciones complementan esta parte con criterios operativos sobre documentación, testing, excepciones y diseño.
Parte 4 toma estas herramientas de calidad y las proyecta sobre soluciones de diseño reutilizables: los patrones.