![\"Dependency](\"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eznvnc2jslo1phhycz5a.png\")
\n\nRepost of https://dev.to/rhuzaifa/why-the-dependency-inversion-principle-is-worth-using-opj
\n
Dependency Inversion is the D of SOLID, and you may wonder, what is SOLID?
\n\n\nSOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.
\n
Rules and Conventions have their place. In code, the SOLID design is considered a convention/best-practice.
\nBasically
\n\n\nHigh-Level Modules Should Not Depend Upon Low-Level Modules. Both Should Depend Upon Abstractions.
\n
Not too difficult. Right? Here is more
\n\n\nAbstractions Should Not Depend Upon Details. Details\nShould Depend Upon Abstractions.
\n
Too confusing? This might help
\n
โ๏ธ Both High-level and Low-level modules should depend on the same Abstraction.
\nโ๏ธ High-level modules should implement abstractions that implement Low-Level modules and vice-versa.
\nโ๏ธ Abstractions can implement different details of the operation.
\nโ High-level modules can implement details surpassing abstractions.
We will continue with the payment example from Open/Close Principle. But for this example at the moment we only accept cash payment.
\ninterface Payment {\n\tpay(): boolean\n}\n\nclass CashPayment implements Payment {\n\tpublic pay(amount){\n\t\t// handle cash payment logic\n\t}\n}\n\nfunction makePayment(amount: number, paymentMethod: Payment){\n\tif(paymentMethod.pay(amount)){\n\t\treturn true;\n\t}\n\treturn false;\n}In this particular example, makePayment() is a high-level module and CashPayment is a low-level module. It clearly has no wrapper/abstraction layer.
Now, what if we want to add credit card payment? We might modify our code like this
\ninterface Payment {\n\tpay(): boolean\n}\n\n// (low-level module)\nclass CashPayment implements Payment {\n\tconstructor(user){\n\t\tthis.user = user\n\t}\n\n\tpublic pay(amount){\n\t\t// handle cash payment logic\n\t}\n}\n\n// (low-level module)\nclass CreditCardPayment implements Payment {\n\tconstructor(user){\n\t\tthis.user = user\n\t}\n\n\tpublic pay(amount, creditCardId){\n\t\t// handle creditCard payment logic\n\t}\n}\n\n\n// (High-level Module)\nfunction makePayment(amount: number, paymentMethod: Payment){\n \n\tif(paymentMethod instanceof CashPayment){\n\t\tif(paymentMethod.pay(amount)){\n\t\t\treturn true;\n\t\t}\n\t}\n\n\tif(paymentMethod instanceof CreditCardPayment){\n\t\tif(paymentMethod.pay(amount,paymentMethod.user.creditCardId)){\n\t\t\treturn true;\n\t\t}\n\t}\n \n \treturn false;\n}This clearly violates the Dependency Inversion principle since the high-level module is implementing details for low-level modules. It also violates the Single Responsibility Principle.
\nUsing Dependency Inversion, we will make wrapper classes or abstractions around cash and credit payment implementations.
\ninterface Payment {\n\tpay(): boolean\n}\n\n// (Wrapper/Abstraction around cash payment)\nclass CashHandler implements Payment {\n\tconstructor(user){\n\t\tthis.user = user\n\t\tthis.CashPayment = new CashPayment();\n\t}\n\n\tpay(amount){\n\t\tthis.CashPayment.pay(amount)\n\t}\n}\n\n// (low-level module)\nclass CashPayment {\n\tpublic pay(amount){\n\t\t// handle cash payment logic\n\t}\n}\n\n\n// (Wrapper/Abstraction around credit card payment)\nclass CreditCardHandler implements Payment {\n\tconstructor(user){\n\t\tthis.user = user\n\t\tthis.CreditCardPayment = new CreditCardPayment();\n\t}\n\n\tpay(amount){\n\t\tthis.CreditCardPayment.pay(amount, this.user.creditCardId)\n\t}\n}\n\n// (low-level module)\nclass CreditCardPayment {\n\tpublic pay(amount, creditCardId){\n\t\t// handle creditCard payment logic\n\t}\n}\n\n\n// (High-level Module)\nfunction makePayment(amount: number, paymentMethod: Payment){\n\tif(paymentMethod.pay(amount)){\n\t\treturn true;\n\t}\n\treturn false;\n}As we can see now our high-level modules are separated by an abstract layer hiding the details of low-level implementation. We inverted the dependencies.
\nConsider This
\n\n\nWe want to add PayPal and WireTransfer Payment Options to our existing code (the example we just did). It can be done easily without touching our existing code. We only have to add low-level and wrapper implementations for PayPal and WireTransfer Payments. Thus, our High-level implementations never break since we are not touching it.
\n
Also
The pattern for other SOLID principles like Interface Segregation and Liskov Substitution is much similar in terms of code breakages i.e : Avoid Them in the long run.
\nHere it is guys. Do you use Dependency Inversion? Be sure to tell me your opinion in the comments and give this article a Heart ๐ if you liked it.
","frontmatter":{"title":"Why The Dependency Inversion Principle Is Worth Using","date":"April 02, 2021","description":"Discover the Dependency Inversion Principle of SOLID design, which ensures abstractions do not depend on details, but the vice versa."}}},"pageContext":{"slug":"/blog/why-the-dependency-inversion-principle-is-worth-using/","previous":{"fields":{"slug":"/blog/is-it-practical-to-use-interface-segregation-principle/"},"frontmatter":{"title":"Is It Practical To Use Interface Segregation Principle?"}},"next":{"fields":{"slug":"/blog/solid-is-it-still-useful-in-2021/"},"frontmatter":{"title":"Solid. Is It Still Useful In 2021?"}}}},"staticQueryHashes":["2276319502"]}