• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Geekebrains

Para programadores, maker y geeks en general

  • Inicio
  • Zona Coders!
  • Zona Makers!
You are here: Home / Qué es ...? / Principios SOLID

4 diciembre, 2022 Por Editor Leave a Comment

Principios SOLID

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

Filed Under: Qué es ...?, Zona Coders!

Previous Post: « Arquitectura Hexagonal – Arquitectura de puertos y adaptadores
Next Post: Unified Modeling Language (UML) »

Reader Interactions

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Primary Sidebar

Categorías

  • Cómo …?
  • Experimentos
  • GeekeBlocks
  • Noticias Geek
  • Proyectos
  • Qué es …?
  • Quién es …?
  • Zona Coders!
  • Zona Junior!
  • Zona makers!

Etiquetas

Arduino base64 Bases de Datos cert Certificados Digitales Clean Code Code Smells DBeaver Diseño de Software docker docker-compose Domain Drive Design https IDE Java javascript jest JSON lenguajes de programación Librerías de JavaScript linux lsoft Material UI MongoDb MySQL NodeJS NoSQL odoo Open Source openssl Oracle package.json Patrones de Diseño de Software pem plugins Postgres Prettier ReactJS Refactoring shell SQL Developer de Oracle SSL TypeScript utilidades de software Visual Studio Code

Entradas recientes

  • JWT
  • Lenguaje ubicuo en Domain-Driven Design (DDD)
  • NestJs
  • Docker-compose y mongoDB: Failed to start up WiredTiger under any compatibility version?
  • Ponerle nombre a las cosas: camelCase, snake_case, kebab-case, PascalCase, MACRO_CASE y Train_Case
  • OBS – Open Broadcaster Software
  • Duck typing
  • Patrón de arquitectura: Backend for Frontend – BFF
  • SaaS, PaaS y IaaS
  • Notion
Jesús A. Carballo Santaclara

Empezé trasteando en los 80' con un ZX espectrum, después pasé al potente "PC 8086" (jeje...). He trabajado haciendo software para la administración pública, para Hospitales, el sector de la Automoción, el sector Bancario, en algún e-Commerce de alguna multinacional y he emprendido en robótica educativa y en buscadores web.
Trabajo de forma profesional en esto de los ordenadores desde hace mas de 25 años espero poder contarte alguna cosa interesante.

Footer

Copyright © 2023 · GeekeZonia · Aviso Legal · Política de Cookies · Política de Privacidad · Log in