Dependency inversion DIP, Dependency injection DI, Control inversion IoC and Factory Patterns

1. Dependency inversion

Dependency Inversion Principle (DIP) is one of the SOLID principles.Core ideaIt is throughabstractDecoupling high-level modules and low-level modules toBoth rely on abstraction rather than concrete implementation。

Reliance on inversion/inversion: The traditional dependency direction is that high-level modules directly call low-level modules, and high-level modules rely on low-level detailed modules at the source code level. DIP reversals this dependency relationship through abstraction, so that the implementation of low-level modules depends on the abstraction defined by high-level at the source code level (Considered as part of a high-level module）。

1.1 The core of the principle of dependency inversion

1. High-level modules do not directly rely on low-level modules, both should rely on abstraction (interfaces or abstract classes, interfaces are defined by high-level modules and are regarded as part of high-level modules).
2. Abstraction does not depend on details, details (specific implementations) should rely on abstraction.

1.2 Dependency inversion guidelines

• Variables cannot hold references to specific classes - use factory instead,Avoid using new to hold references to specific classes directly (the operations of new specific classes are encapsulated into the factory)
• Don't let classes derive from concrete classes - derived from abstract classes or interfaces, so you don't rely on concrete classes.
• Don't override methods that have been implemented in the base class - if this is the case, it means that it is not a truly suitable abstraction for inheritance

1.3 Example

Scene

• High-rise modulesReportGeneratorReports need to be generated and rely on data acquisition function.
• Low-level moduleMySQLDatabaseandSQLiteDatabaseProvide specific data operations.

Traditional implementation (DIP not followed)

// Low-level module: Directly rely on specific implementation
 class MySQLDatabase {
 public:
     void connect() { /* MySQL connection logic */ }
     std::string fetchData() { return "MySQL data"; }
 };

 // High-level modules directly rely on low-level specific classes
 class ReportGenerator {
 private:
     MySQLDatabase db; // Directly depend on specific implementation
 public:
     void generateReport() {
         ();
         auto data = ();
         std::cout << "Report data: " << data << std::endl;
     }
 };

question：ReportGeneratorDirect dependencyMySQLDatabase, changing the database (if using SQLite instead) requires modifying the high-level code.

Follow DIP implementation

1. Define abstract interfaces：

class Database {
public:
    virtual ~Database() = default;
    virtual void connect() = 0;
    virtual std::string fetchData() = 0;
};

2. Low-level module implementation interface：

class MySQLDatabase : public Database {
 public:
     void connect() override { /* MySQL connection logic */ }
     std::string fetchData() override { return "MySQL data"; }
 };

 class SQLiteDatabase : public Database {
 public:
     void connect() override { /* SQLite connection logic */ }
     std::string fetchData() override { return "SQLite data"; }
 };

3. High-level module dependency abstraction：

class ReportGenerator {
 private:
     Database& db; // Depend on abstract interface
 public:
     ReportGenerator(Database& database) : db(database) {} // Dependency injection
     void generateReport() {
         ();
         auto data = ();
         std::cout << "Report data: " << data << std::endl;
     }
 };

4. Example of usage：

int main() {
     MySQLDatabase mysqlDb;
     SQLiteDatabase sqliteDb;

     ReportGenerator report1(mysqlDb); // Use MySQL
     ();

     ReportGenerator report2(sqliteDb); // Use SQLite
     ();

     return 0;
 }

1.4 Dependency inversion advantage

• Decoupling: High-level modules do not rely on low-level implementations, and can flexibly replace databases (such as new ones)MongoDBJust implementDatabaseinterface).
• Maintainability: Modify low-level code (such as optimizationMySQLDatabase) does not affect high-level modules.
• Testability: Can be implemented through Mock object (implementedDatabaseInterface) Easy to testReportGenerator。

1.5 Dependency inversion summary

The principle of dependency inversion changes dependencies from "high-level → low-level" to "high-level → abstract ← low-level" through abstract decoupling modules, thereby improving the flexibility and maintainability of the system. In C++, this principle can be implemented through abstract classes (interfaces) and dependency injection (such as constructors passing interface pointers/references).

2. Dependency injection DI

Dependency injection (Dependency Injection, DI) is a kindExternalization technology for object dependencies, its core idea is:Objects do not create or manage their own dependencies directly, but provide instances of dependencies by external (caller or framework). In this way, the coupling of the code is reduced, and the flexibility and testability are significantly improved.

2.1 The nature of dependency injection

1. Inversion of control (IoC)
   Dependency injection is an implementation of control inversion. In traditional code, objects control the creation of dependencies themselves (such asnewa concrete class), while dependency injection handes this control to the outside, implementing "Dependencies are injected into the object”。
2. Rely on abstraction rather than implementation
   Dependency injection is usually used in conjunction with interfaces or abstract classes to ensure that objects rely on abstraction rather than concrete implementations (comply withReliance inversion principle）。

2.2 Three ways of dependency injection

1. Constructor injection (most commonly used)

Passing dependencies through constructors ensures that the object has complete dependencies when it is created.

class NotificationService {
 private:
     MessageSender& sender; // Depend on abstract interface
 public:
     NotificationService(MessageSender& sender) : sender(sender) {} // Constructor injection
     void sendMessage(const std::string& msg) {
         (msg);
     }
 };

2. Property injection (Setter injection)

Dynamically set dependencies through exposed member properties or Setter methods.

class NotificationService {
 public:
     void setSender(MessageSender& sender) { // Setter injection
         this->sender = &sender;
     }
 private:
     MessageSender* sender;
 };

3. Method Injection

Passing dependencies through method parameters is suitable for temporary or local dependencies.

class NotificationService {
 public:
     void sendMessage(MessageSender& sender, const std::string& msg) { // Method injection
         (msg);
     }
 };

2.3 Why do dependency injection need?

1. Decoupling and maintainability

• Traditional code: Dependencies are created directly inside the object, resulting in tight coupling.

class UserService {
private:
MySQLDatabase db; // Directly depend on specific classes
};

If you need to use `SQLiteDatabase` instead, you must modify the code of `UserService`.

 - **Dependency injection**: Decoupling through the interface, only different implementations are required.

 ```cpp
 class UserService {
 private:
     Database& db; // Dependency abstraction
 public:
     UserService(Database& db) : db(db) {}
 };

2. Testability

• Dependency injection allows for replacement with a Mock object when tested.

  class MockDatabase : public Database { /* Simulation implementation */ };
  
   TEST(UserServiceTest) {
       MockDatabase mockDb;
       UserService service(mockDb); // Inject Mock object
       // Perform the test...
   }

3. Extensibility

• When new features are added, you only need to implement new dependencies and inject them without modifying existing code.

  class MongoDB : public Database { /* New database implementation */ };
  
   MongoDB mongoDb;
   UserService service(mongoDb); // Directly inject new dependencies

2.4 Practical skills of C++ dependency injection

1. Manage life cycles with smart pointers

Avoid memory leaks caused by naked pointers and usestd::shared_ptrorstd::unique_ptr。

cpp

class NotificationService {
 private:
     std::shared_ptr<MessageSender> sender; // Intelligent pointer management dependency
 public:
     NotificationService(std::shared_ptr<MessageSender> sender) : sender(sender) {}
 };

2. Combined with factory model

Centrally manage the creation logic of dependencies through factory classes.

class SenderFactory {
 public:
     static std::shared_ptr<MessageSender> createSender(const std::string& type) {
         if (type == "email") return std::make_shared<EmailSender>();
         else return std::make_shared<SmsSender>();
     }
 };

 // Create dependencies using factory
 auto sender = SenderFactory::createSender("email");
 NotificationService service(sender);

3. Dependency injection container (IoC Container)

In complex projects, use containers to automatically manage dependencies (such as ).

#include <boost/>
 namespace di = boost::di;

 // Define interfaces and implementations
 class Database { /* ... */ };
 class MySQLDatabase : public Database { /* ... */ };

 // Configure containers
 auto injector = di::make_injector(
     di::bind<Database>().to<MySQLDatabase>()
 );

 // Automatically inject dependencies
 class UserService {
 public:
     UserService(Database& db) { /* ... */ }
 };
 UserService service = <UserService>();

2.5 Common misunderstandings of dependency injection

1. Dependency injection ≠ Factory mode
   The factory pattern is responsible for creating objects, while dependency injection is responsible for passing objects. The two are often used in combination, but have different purposes.
2. Dependency injection ≠ Must use framework
   Dependency injection can be implemented even without a framework (such as ), passing dependencies through constructors or parameters.
3. Overinjection problem
   If a class needs to inject too many dependencies (such as more than 4), there may be problems with the design and the splitting responsibility needs to be considered.

2.6 Dependency injection summary

• The core of dependency injection: Transfer dependencies' creation and binding from inside the object to outside.

• Core Value: Decoupling, testable, scalable.

• C++ implementation key:

  • Abstract dependencies through interfaces.
  • Pass dependencies using constructor/smart pointer.
  • CombinedFactory modelOr IoC containers manage complex dependencies.

3. Control Inversion IoC

IoC (Inversion of Control)It's a kindSoftware Design Principles, its core idea isTransfer control of program flow from the developer to the framework or container, to reduce the coupling of the code, improve modularity and maintainability. It is a key mechanism for implementing the Dependency Inversion Principle (DIP) and the basis of modern frameworks (such as Spring, .NET Core) and Dependency Injection (DI) containers.

3.1 Control Inversion IoC vs. Dependency Injection DI

• IoC (Control Inversion): A broad design principle, representing the paradigm of transfer of control. Its essence isTransfer control of program flow from developers to frameworks or containers。
• DI (dependency injection): A specific implementation technology of IoC, which passes dependencies through external transit.

relation：

• Dependency injection is one of the implementations of control inversion.
• Control inversion can also be achieved through template methods, callbacks (association: Hollywood principles), etc.
• Use IoC containers (such as ) to automatically manage complex dependencies.

4. Factory model

Although both dependency inversion and dependency injection emphasize abstract programming, in actual encoding, it is still necessary to create (new) concrete underlying components (ConcreteClass)

The factory model is mainly divided into three types, strictly speaking, it includesSimple factory mode、Factory method modeandAbstract factory pattern. The following are their core differences, applicable scenarios and C++ examples:

4.1 Simple Factory

Sometimes simple factories are not considered formal design patterns, but rather a programming habit.

Core idea

• Through a factory class, according to the incomingparameterDecide which specific product object to create.
• Not in compliance with the principle of opening and closing(New products need to modify the factory logic).

Applicable scenarios

• There are fewer product types and simple creation logic.
• No need to expand new types frequently.

C++ Example

// Abstract product
 class Shape {
 public:
     virtual void draw() = 0;
     virtual ~Shape() = default;
 };

 // Specific products
 class Circle : public Shape {
 public:
     void draw() override { std::cout << "Draw a circle" << std::endl; }
 };

 class Square : public Shape {
 public:
     void draw() override { std::cout << "Draw a square" << std::endl; }
 };

 // Simple factory
 class ShapeFactory {
 public:
     static Shape* createShape(const std::string& type) {
         if (type == "circle") return new Circle();
         else if (type == "square") return new Square();
         else return nullptr;
     }
 };

 // Use example
 int main() {
     Shape* circle = ShapeFactory::createShape("circle");
     circle->draw(); // Output: Draw a circle
     delete circle;
     return 0;
 }

4.2 Factory Method

Core idea

• Define an object that createsAbstract Methods, the subclass determines which class to instantiate.
• Comply with the principle of opening and closing(Add new products only require a new sub-factory).

Applicable scenarios

• Product types may expand frequently.
• Object creation needs to be delayed to subclasses.

C++ Example

// Abstract product
 class Database {
 public:
     virtual void connect() = 0;
     virtual ~Database() = default;
 };

 // Specific products
 class MySQL: public Database {
 public:
     void connect() override { std::cout << "Connect to MySQL" << std::endl; }
 };

 class PostgreSQL : public Database {
 public:
     void connect() override { std::cout << "Connect to PostgreSQL" << std::endl; }
 };

 // Abstract factory
 class DatabaseFactory {
 public:
     virtual Database* createDatabase() = 0;
     virtual ~DatabaseFactory() = default;
 };

 // Specific factory
 class MySQLFactory : public DatabaseFactory {
 public:
     Database* createDatabase() override { return new MySQL(); }
 };

 class PostgreSQLFactory : public DatabaseFactory {
 public:
     Database* createDatabase() override { return new PostgreSQL(); }
 };

 // Use example
 int main() {
     DatabaseFactory* factory = new PostgreSQLFactory();
     Database* db = factory->createDatabase();
     db->connect(); // Output: Connect to PostgreSQL
     delete db;
     delete factory;
     return 0;
 }

4.3 Abstract Factory

Core idea

• Provides an interface for creatingRelated or dependent object family, without specifying specific classes.
• Abstract factory containsMultiple factory methods, Each method is responsible for creating objects in a product family.

Applicable scenarios

• You need to create a set of related or dependent objects (such as GUI components: buttons, text boxes, drop-down menus, etc.).
• The system needs to be created, combined, and represented independently of the product.

C++ Example

// Abstract product: button
 class Button {
 public:
     virtual void render() = 0;
     virtual ~Button() = default;
 };

 // Specific product: Windows button
 class WindowsButton : public Button {
 public:
     void render() override { std::cout << "Windows Style Button" << std::endl; }
 };

 // Specific product: MacOS button
 class MacOSButton : public Button {
 public:
     void render() override { std::cout << "MacOS style button" << std::endl; }
 };

 // Abstract product: text box
 class TextBox {
 public:
     virtual void display() = 0;
     virtual ~TextBox() = default;
 };

 // Specific product: Windows text box
 class WindowsTextBox : public TextBox {
 public:
     void display() override { std::cout << "Windows-style text box" << std::endl; }
 };

 // Specific product: MacOS text box
 class MacOSTextBox : public TextBox {
 public:
     void display() override { std::cout << "MacOS style text box" << std::endl; }
 };

 // Abstract factory
 class GUIFactory {
 public:
     virtual Button* createButton() = 0;
     virtual TextBox* createTextBox() = 0;
     virtual ~GUIFactory() = default;
 };

 // Specific factory: Windows style components
 class WindowsFactory: public GUIFactory {
 public:
     Button* createButton() override { return new WindowsButton(); }
     TextBox* createTextBox() override { return new WindowsTextBox(); }
 };

 // Specific factory: MacOS style components
 class MacOSFactory : public GUIFactory {
 public:
     Button* createButton() override { return new MacOSButton(); }
     TextBox* createTextBox() override { return new MacOSTextBox(); }
 };

 // Use example
 int main() {
     GUIFactory* factory = new MacOSFactory();

     Button* button = factory->createButton();
     button->render(); // Output: MacOS style button

     TextBox* textBox = factory->createTextBox();
     textBox->display(); // Output: MacOS style text box

     delete button;
     delete textBox;
     delete factory;
     return 0;
 }

4.4 Comparison of three factory modes

model	Core objectives	Extensibility	Applicable scenarios
Simple factory	Centrally create different objects of a single type	Poor (required to modify the factory class)	A small number of fixed types without frequent expansion
Factory Method	Delay object creation to subclass	OK (new factory subcategory)	Single product, type may be expanded frequently
Abstract factory	Create multiple related or dependent object families	OK (new factory subcategory)	Multiple related products need to maintain style consistency

4.5 Factory model summary

• Simple factory: Suitable for simple scenarios, but violates the principle of opening and closing.
• Factory Method: Solve the expansion problem of a single product.
• Abstract factory: Solve the problem of creating multiple products and emphasize the correlation between products.

Choose the appropriate model according to the needs: if the product is single and can be expanded, use the factory method; if you need to create a set of associated objects, use an abstract factory; if the product type is fixed and simple, use a simple factory.

5. Summary

Dependency inversion (DIP), dependency injection (DI), control inversion (IoC), and factory patterns are closely related concepts in software design, and they collectively serve the decoupling and maintainability of code.

5.1 Related

• Dependency Inversion Principle (DIP): High-level modules do not rely on low-level modules, both rely on abstractions (interfaces or abstract classes). This idea guides the design direction of factory models, DI and IoC.

• Inversion of Control (IoC): Transfer object creation and lifecycle management rights from within the program to external containers (such as frameworks). For example: dependencies are created and injected by external containers (such as factories or frameworks), rather than creating dependencies directly. Factory pattern and dependency injection DI are specific ways to implement IoC.

• Dependency Injection (DI): Dependency Injection (DI): Through constructors, setters, or interfaces, the dependency object isPassive deliveryTo the user. It is a specific technical means to realize IoC. Factory pattern is often used to generate these dependencies.

• Factory Pattern: Encapsulates specific object creation logic and creates objects uniformly through factory classes. It is one of the means to implement IoC, hiding instantiation details and supporting DIP and DI. It is the underlying support for dependency injection DI and control inversion IoC.

The common goal of the four isDecoupled code, improve scalability and maintainability.

5.2 Example full link

// 1. Follow DIP: Define abstract interfaces
 class IStorage { /* ... */ };

 // 2. Specific implementation
 class DatabaseStorage : public IStorage { /* ... */ };

 // 3. Factory mode: Encapsulation object creation
 class StorageFactory {
 public:
     static IStorage* createStorage() { return new DatabaseStorage(); }
 };

 // 4. Dependency injection: Passing objects through constructor
 class UserService {
 private:
     IStorage* storage;
 public:
     UserService(IStorage* storage) : storage(storage) {}
 };

 // 5. Control inversion: Dependencies are created by the factory, not internally by the UserService
 int main() {
     IStorage* storage = StorageFactory::createStorage();
     UserService userService(storage); // DI injection
     ();
     delete storage;
     return 0;
 }