Principio de Responsabilidad Única. Single Responsability Principle (SRP)
Cada clase debe tener una responsabilidad única, así que solo debería tener un único método publico.
Se deben evitar las clase de tipo MailService, InvoiceManager, etc. Que implican que hacen muchas cosas.
Como saber que una clase/módulo tiene demasiadas resposabilidades:
Si una misma clase/módulo esté involucradas en dos capas distintas de la arquitectura. (Ej: Modelo, Vista, Acceso a Datos,…).
Si tiene muchos métodos públicos.
Si tiene muchos imports.
Si cuando cambias algo en el programa te obliga a cambiar dicha clase.
Si tiene demasiadas lineas de código.
Principio de Abierto/Cerrado. Open Close Principle (OCP)
El software debe estar abierto a la extensión y cerrado a las modificaciones.
A nivel de clases podemos estar abiertos a extensión gracias al uso de Interfaces, que establezcan un contrato al que acoplarnos para no tener que depender de implementaciones concretas.
Principio de sustitución de Liskov. Liskov Sustitution Principle (LSP)
El principio de sustitución de Liskov nos dice que si en alguna parte de nuestro código estamos usando una clase B, y esta clase extiende a una padre A, tenemos que poder cambiar B por la clase padre A o por otra hija y que el programa debe poder seguir funcionando correctamente.
Osea que las clases hijas extendidas deben mantener el contrato de la clase padre, las misma firmas y las misma ideas de funcionamiento.
El objetivo es que se pueda aplicar el el Open Close Principle.
Principio de segregación de interfaces. Interface Segregation Principle (SIP)
Las interfaces pertenecen a los clientes. No empezar a crear interfaces y añadir cosas «por si acaso» sino solo justo lo necesario.
Utilizar interfaces con contratos en base a los clientes que las van a utilizar ayudará a que nuestro código tenga Alta cohesión y bajo acoplamiento estructural.
Principio de inversión de dependencias. Dependency Inversion Principle (DIP)
Elemento principal de la Arquitectura Hexagonal. Diferenciando entre inyección e inversión de dependencias. Las dependencias que va a necesitar una clase, se inyectan en el constructor. Así cambiar de dependencia no requiere ningún cambio en la clase. Esto ayuda a hacer los test mucho mas sencillos.
Specification pattern
Composición sobre herencia. Composition over Inheritance
¿Qué significa el acrónimo STUPID? El Antipatrón.
- Singleton:
- Evita exponer los colaboradores de una clase (algo negativo ya que hace más difícil de detectar el acoplamiento entre clases).
- Además, el beneficio del que provee es básicamente mantener un estado global, algo que podemos conseguir vía inyección de dependencias como veremos en el curso.
- Por último, derivado de los puntos anteriores, perjudica la testabilidad de nuestras clases haciéndolas más difícil de aislar, ya que no podremos doblar en tiempo de test ese Singleton de forma fácil.
- Tight Coupling: Acoplamiento entre clases que dificulta la mantenibilidad y tolerancia al cambio que proporciona la aplicación de principios SOLID
- Untestability: Código difícil de testear. Derivado de no inyectar dependencias vía constructor nos vemos obligados al uso de costuras en nuestro código.
- Premature Optimization: Anticiparnos a los requisitos de nuestro software desarrollando abstracciones innecesarias que añaden complejidad.
- Indescriptive Naming: Nomenclatura indescriptiva tanto a nivel de clases, como variables o atributos. ¡Hablaremos más de esto en el curso de Clean Code!
- Duplication: Duplicidad de código. Algo solucionable si aplicamos el Principio de Responsabilidad Única de SOLID e inyección de dependencias como veremos en este curso