SOLID - Dependency Inversion Principle (DIP)

SOLID - Dependency Inversion Principle (DIP)

Dependency Inversion Principle emphasizes decoupling and abstraction in software systems by defining guidelines for dependency relationships between modules or classes.

High-level modules should not depend on low-level modules. Both should depend on abstractions.

In simpler terms, DIP encourages the use of interfaces or abstract classes to define contracts and dependencies between modules, rather than depending on concrete implementations. This allows for flexibility, extensibility, and easier maintenance of the codebase.

To adhere to DIP, the following practices are recommended:

  • Programming to interfaces or abstract classes rather than concrete implementations.
  • Using dependency injection to provide dependencies to classes rather than instantiating them directly.
  • Employing dependency inversion frameworks or inversion of control containers to manage object dependencies.

DIP and Multiple Inheritance

This is a special case of Dependency Inversion Principle (DIP) with multiple inheritance in Python.

class MyInterface(ABC):
    @abstractmethod
    def method(self):
        pass

class MyBaseClass:
    def base_method(self):
        print("Base method")

class MyImplementation(MyInterface, MyBaseClass):
    def method(self):
        print("Implementation of method")        

class MyClient:
    def __init__(self, interface_obj: MyInterface):
        self.interface_obj = interface_obj

    def perform_operation(self):
        self.interface_obj.method()

my_interface_impl = MyImplementation()
client = MyClient(my_interface_impl)
client.perform_operation()

In the provided example, where MyImplementation inherits from both MyInterface and MyBaseClass, and the methods of MyBaseClass are only used internally within MyImplementation, it can be acceptable to use them.

Since MyBaseClass is not exposed externally and its methods are used only within the implementation details of MyImplementation, it does not violate the Dependency Inversion Principle (DIP). The DIP mainly focuses on the dependencies of higher-level modules or objects, ensuring that they depend on abstractions rather than concrete implementations. As long as the external interface of MyImplementation adheres to MyInterface, it can utilize internal implementation details as needed.

However, it's still important to be cautious and ensure that the internal usage of MyBaseClass methods aligns with the design and intent of your code. If there is a possibility that the internal usage might evolve to be part of the public interface or if the dependency becomes more significant, it may be worth reconsidering the design to further decouple the dependencies and promote cleaner abstraction boundaries.

You can see a working code example here:

https://github.com/robson-koji/FullTextSearch-Validator/blob/main/full_text_search_validator.py

Popular posts from this blog

Atom - Jupyter / Hydrogen

Image
I will show you how to use the Atom editor with Jupyter Notebook to debug Python/Django views using Hydrogen plugin. On the Internet you can find some examples using this setup to debug Python but I found nothing related to Django, so I decided to publish this notes. This is not a high performance setup, because it involves many technologies at several layers. This is more a proof of concept of nowadays technologies which are available to the programmer's toolbox. This notes has been written during the development and improvement of the automated tests of the Virtual Library of FAPESP ( http://www.bv.fapesp.br ). The environment The diagram below shows an actual infrastructure to use this setup in a development environment. Technologies It is not expected that you know all of the technologies in detail, but there are some trick points. This paper is oriented for Python programmer who already use Atom and Jupyter and enjoy explore the edges of these tools.
Read more

Design Patterns

Design Patterns Creational Patterns These patterns focus on object creation mechanisms, providing flexibility and decoupling the client code from the specific classes instantiated. Some examples of creational patterns are: Singleton: Ensures that only one instance of a class exists throughout the program. Factory: Provides an interface for creating objects, but allows subclasses to decide which class to instantiate. Builder: Separates the construction of complex objects from their representation, allowing the same construction process to create different representations. Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Prototype: Creates new objects by cloning existing ones and modifying them as needed. Structural Patterns These patterns deal with the composition of classes and objects, focusing on how they can be organized to form larger structures while keeping them flexible and ef
Read more

Robson Koji Moriya disambiguation name

Image
Robson Koji Moriya This page is dedicated to my name and other similar names found on the Internet. The purpose of this page is to assist search engines like Google, Bing, Yahoo, and others in understanding that I am a distinct individual and that there are other people with similar names. I will also share some interesting facts with you. Search Engines It is interesting to note that Bing does a much better job than Google when it comes to indexing my name. When I search for "Robson Koji Moriya" on both search engines, Google displays a lot of other individuals with the names "Robson Koji" and "Moriya," but it doesn't show most of my own online publications. Even this blog, which has my complete name in its domain, is hidden by Google. On the other hand, Bing correctly displays most of my information. Yahoo search engine is powered by Bing through a partnership. Google and Ask.com produce very similar results, and unfortunately, they are mostly incorr
Read more