Principio de inversión de dependencia (SÓLIDO)

Comprendamos uno de los principios clave del grupo de principios SOLID, a saber, el principio de inversión de dependencia.

El principio de inversión de dependencia es uno de los principios sobre los que se basan la mayoría de los patrones de diseño. La inversión de dependencia habla del acoplamiento entre las diferentes clases o módulos. Se centra en el enfoque en el que las clases superiores no dependen de las clases inferiores, sino que dependen de la abstracción de las clases inferiores. El lema principal de la inversión de dependencia es Cualquier clase superior debería depender siempre de la abstracción de la clase en lugar de los detalles .

Esto tiene como objetivo reducir el acoplamiento entre las clases mediante la introducción de la abstracción entre la capa, por lo que no se preocupa por la implementación real.

Entendamos el principio de inversión de dependencia con un ejemplo. Digamos que usted es un gerente que tiene algunas personas como empleados, algunos de los cuales son desarrolladores y otros son diseñadores gráficos y el resto son probadores.

Ahora veamos cómo se vería un diseño ingenuo sin ninguna inversión de dependencia y cuáles son las lagunas en ese diseño.

class Manager(object):
    def __init__(self):
        self.developers=[]
        self.designers=[]
        self.testers=[]
  
    def addDeveloper(self,dev):
        self.developers.append(dev)
          
    def addDesigners(self,design):
        self.designers.append(design)
          
    def addTesters(self,testers):
        self.testers.append(testers)
  
      
class Developer(object):
    def __init__(self):
        print "developer added"
      
class Designer(object):
    def __init__(self):
        print "designer added"
      
class Testers(object):
    def __init__(self):
        print "tester added"
      
if __name__ == "__main__":
    a=Manager()
    a.addDeveloper(Developer())
    a.addDesigners(Designer())

Output :
  developer added
  designer added

Esto se puede visualizar fácilmente mediante el siguiente diagrama UML.

Ahora, echemos un vistazo a los agujeros de bucle de diseño en el código fuente:
primero, ha expuesto todo sobre la capa inferior a la capa superior, por lo que no se menciona la abstracción. Eso significa que el gerente ya debe conocer el tipo de trabajadores que puede supervisar.

Ahora, si otro tipo de trabajador está bajo el mando del gerente, digamos QA (garantía de calidad), entonces toda la clase necesita ser reorganizada. Aquí es donde entra en juego el principio de inversión de dependencia.

Veamos cómo resolver el problema en mayor medida utilizando el principio de inversión de dependencia.

   
class Employee(object):
    def Work():
        pass
      
class Manager():
    def __init__(self):
        self.employees=[]
    def addEmployee(self,a):
        self.employees.append(a)
   
class Developer(Employee):
    def __init__(self):
        print "developer added"
    def Work():
        print "turning coffee into code"
          
class Designer(Employee):
    def __init__(self):
        print "designer added"
    def Work():
        print "turning lines to wireframes"
          
class Testers(Employee):
    def __init__(self):
        print "tester added"
    def Work():
        print "testing everything out there"
          
if __name__ == "__main__":
    a=Manager()
    a.addEmployee(Developer())
    a.addEmployee(Designer())

Output :
  developer added
  designer added

Ahora, si se agrega cualquier otro tipo de empleado, simplemente se puede agregar al Gerente sin que el gerente lo sepa explícitamente. Ahora, para agregar otra clase de empleado, simplemente podemos llamar

class QA(Employee):
        def Work():
             print "testing everything out there"
a.add(QA())

La creación de la abstracción entre los diferentes empleados y el Gerente ha dado como resultado un código de diseño muy atractivo que es fácil de mantener y ampliar. Eche un vistazo al diagrama UML a continuación.

En este código, el gerente no tiene una idea de antemano sobre todo el tipo de trabajadores que pueden estar bajo él / ella, lo que hace que el código sea realmente desacoplado. Hay muchos patrones de diseño en los que esta es una idea central y otras cosas se basan en ella.