Header Ads Widget

Ticker

6/recent/ticker-posts

Principio de inversión de dependencia

 

El principio de inversión de dependencia nos lleva a la conclusión de estudiar los cinco principios sólidos de diseño que provienen de Bertrand Meyer, Barbara Liskov, Robert Martin y Tom DeMarco, entre otros. Si estos cinco artículos te dan vueltas, no temas. Estamos lidiando con abstracciones, y las abstracciones pueden empezar a jugarle una mala pasada a tu mente después de un tiempo. Aprender sobre estos patrones de diseño es una excelente manera de practicar su oficio. Todos estamos tratando de dominar la cantidad ilimitada de complejidad que acompaña a la programación de computadoras. Todos estos principios intentan hacer las cosas más fáciles de razonar y limitar el tamaño de cualquier módulo. Echemos un vistazo al principio final de esta sólida serie ahora.

¿Qué significa el principio de inversión de dependencia?

Comencemos con la definición formal y luego repasemos.

1. Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.


2. Las abstracciones no deben depender de los detalles. Los detalles deberían depender de abstracciones.

¿Qué hay de los términos de Layman, por favor?

Lo que significa el principio de inversión de dependencia es que el software no debe tener dependencia de una manera. El tío Bob siempre se refiere a esto como la dirección en la que las flechas apuntan entre módulos. Por ejemplo, si tiene tres módulos y todos apuntan de izquierda a derecha en un nivel alto a bajo, entonces no tiene inversión de dependencia. En cambio, deberíamos tener módulos de alto nivel que dependan de una abstracción (interfaz) y módulos de bajo nivel que también dependan de la misma abstracción. De esta manera, no solo puede intercambiar y reutilizar los módulos de bajo nivel, sino que también puede intercambiar y reutilizar los módulos de alto nivel. Consulte los dos ejemplos más comunes que se utilizan para describir cómo funciona la inversión de dependencia.

Ejemplo de inversión de dependencia de mango y punta

ejemplo uno de inversión de dependencia
Aquí mismo tenemos un ejemplo de un módulo de alto nivel (The Handle) y un módulo de bajo nivel (The Tips) que dependen de la misma abstracción (The hexagonal shape). No solo puede cambiar las puntas como desee (módulos de bajo nivel), sino que también puede cambiar los Handles (módulos de alto nivel) como desee. Esta es la verdadera inversión de dependencia. Aquí está mi mejor intento de implementar esto en el código. Si tiene una mejor solución, hágamelo saber para que pueda actualizarla (comuníquese con @vegibit)

¡Frio! No importa qué mango o punta elijamos, siempre que hagan uso de la forma hexagonal de nuestra interfaz, podemos intercambiar y enchufar y jugar a voluntad.

El ejemplo de inversión de dependencia del enchufe de alimentación

ejemplo dos de inversión de dependencia
Otro ejemplo del principio de inversión de dependencia es el del enchufe de alimentación estándar. Una casa tiene un medio o una interfaz para proporcionar energía, y eso es a través del enchufe de pared estándar. Tenemos todo tipo de fabricantes de aparatos electrónicos que quieren venderte sus productos, pero dependen de la electricidad para funcionar. Las personas brillantes que construyen estas cajas no dejan que usted averigüe cómo hacer que esos dispositivos tengan energía. Son lo suficientemente inteligentes como para adaptarse a la interfaz que necesitarán usar. La casa dice, proporcionaré energía, pero solo lo haré a través de esta interfaz. Los fabricantes de gadgets implementan con gusto esa interfaz, y ahora puede conectar su Xbox, Playstation, Nintendo, cargador de iPhone, refrigerador, Ultra HD Tv y más en la interfaz dada (la toma de corriente).

¿Quién posee la interfaz?

El tío Bob habla de este concepto como una arquitectura enchufable, donde los módulos se pueden intercambiar a través de un sistema enchufable. Ahora, el principio de inversión de la dependencia invierte la forma en que podríamos pensar sobre la dependencia, y hace que los módulos de nivel alto y bajo sean intercambiables. Sin embargo, al final del día, alguien suele ser dueño de la interfaz. En una de sus presentaciones, lo expresa elocuentemente como "¿quién se va a arruinar si cambia esta interfaz?" o "¿Quién tiene realmente el control aquí?" Es un tema fascinante y me recuerda cómo piensa Lawrence Lessig sobre el software y el código.


Más recursos sobre diseño sólido en programación orientada a objetos

Consulte estos excelentes recursos que ayudaron a respaldar los conceptos de este artículo.


Principios SOLID de Bob Martin del diseño ágil y orientado a objetos

Anthony Ferrara le ayuda a captar SÓLIDO

  • Scotch.io cubre sólida
  • Más información sobre solid en Laracasts
  • La fama de Fideloper of Vaprobash y Servers for Hackers cubre la arquitectura hexagonal
  • El principio de responsabilidad única
  • El principio abierto cerrado
  • El principio de sustitución de Liskov
  • El principio de segregación de interfaces
  • El principio de inversión de dependencia

Resumen del principio de inversión de dependencias

Esto concluye nuestro estudio informal no solo del Principio de Inversión de Dependencia, sino también de todo el conjunto de conceptos en el ámbito sólido. Vale la pena señalar que estas no son reglas estrictas, sino filosofías y patrones de diseño para guiarnos. Me gusta mucho la forma en que Anthony Ferrara lo resume en su charla. Al final del día, nuestro objetivo es proporcionar valor comercial y utiliza el hockey como analogía. Él compara esto con un gol limpio (sólido) versus un gol sucio (espagueti) en el hockey. Cuando ocurre el gol limpio, todos nos maravillamos de la belleza y delicadeza con la que se marcó el gol. Es posible que lo veamos en los carretes destacados de manera similar a como lo haríamos en un blog sobre un código bellamente diseñado. ¡El gol sucio no es menos valioso! A pesar de que el jugador puede haberse tropezado consigo mismo y aterrizado de cara al hielo, de alguna manera, el disco se soltó de su palo y pudo resbalar por el portero. Puede que no haya sido bonito, podría haber sido francamente feo. Sin embargo, la verdad es que ese feo gol pudo haber ganado el juego. En el software, es posible que tenga algunos goles sucios (como todos los tenemos), pero si se trata de marcar goles, todavía está ganando.



Publicar un comentario

0 Comentarios