设计模式-03 设计模式-依赖倒转原则案例分析


设计模式-03 设计模式-依赖倒转原则案例分析

目录

设计模式-02 设计模式-依赖倒转原则案例分析

1.定义

2.内涵

3.案例对比

4.注意事项

5.最佳实践

6.总结


1.定义

依赖倒转原则(Dependency Inversion Principle,简称DIP)高层级的模块不能依赖底层级模块的,两种层级的模块应该依赖抽象,抽象层不能依赖具体实现层,具体实现应该依赖抽象

通俗来说,DIP 意味着:

客户端代码(高层模块)不应该直接依赖于具体实现(低层模块)。
相反,客户端代码应该依赖于一个抽象,而抽象再依赖于具体实现。


                   +--------------+
                   |  客户端代码  |
                   +--------------+
                         |
                         V
                   +--------------+
                   |    抽象类    |
                   +--------------+
                         |
                         V
                   +--------------+
                   | 具体实现类 |
                   +--------------+

说明:

  • 客户端代码(高层模块)依赖于抽象类,而不是具体的实现类。
  • 抽象类定义了客户端代码所需的行为,而具体实现类提供了这些行为的具体实现。
  • 客户端代码通过依赖注入接收其依赖项(抽象类)。
  • 通过使用 DIP,客户端代码与具体实现类之间的耦合最小化,从而提高了代码的灵活性、可测试性和可维护性。

                   

2.内涵

DIP 的定义出发点是:

软件的灵活性:当依赖关系是固定的时,很难在不影响其他模块的情况下修改软件。
软件的可测试性:当客户端代码直接依赖于具体实现时,很难对客户端代码进行单元测试。

3.案例对比

错误的设计,经常是依赖与具体的实现。而不是依赖与接口层。以下就具体案例进行的举例说明。


bad 设计

#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

enum class Relationship{
    parent,
    child,
    sibling,
};

struct Person{
    string name;
};

struct Relationships  // 底层模块
{
    vector> relations;

    void add_parent_add_child(const Person& parent, const Person& child){
        relations.push_back({parent, Relationship::parent, child});
        relations.push_back({child, Relationship::child, parent});
    }

};

struct Research  // 上层模块,依赖与底层的具体实现,而不是抽象接口,违反了依赖倒转原则
{
    Research(Relationships& relationships){
        auto& relations = relationships.relations;
        for(auto& [first, rel, second]: relations){
            if(first.name == "Hohn"  && rel == Relationship::parent){
                cout<<"Hohn has child :"<< second.name<< endl;
            }
        }
    }
};

int main() {
    Person parent{"Hohn"};
    Person child1{"Dhris"},child2{"Watt"};
    Relationships relationships;
    relationships.add_parent_add_child(parent,child1);
    relationships.add_parent_add_child(parent,child2);
    Research _(relationships);
    return 0;
}

好的设计

#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

enum class Relationship{
    parent,
    child,
    sibling,
};

struct Person{
    string name;
};

struct RelationshipBrowser{
    virtual vector find_all_children_of(const string& name) = 0;
};

struct Relationships :RelationshipBrowser // 底层模块
{
    vector> relations;

    void add_parent_add_child(const Person& parent, const Person& child){
        relations.push_back({parent, Relationship::parent, child});
        relations.push_back({child, Relationship::child, parent});
    }

    vector find_all_children_of(const string &name) override {
        vector result;
        for(auto&& [first,rel,second] : relations) {
            if(first.name == name && rel == Relationship::parent){
                result.push_back(second);
            }
        }
        return result;
    }


};


struct Research  // 上层模块不在依赖 Relationships ,而是依赖接口:RelationshipBrowser
{

    Research(RelationshipBrowser& browser){
        for(auto& child: browser.find_all_children_of("Hohn")){
            cout<<"Honh has child:"<< child.name<

两种设计思路输出结果一样,但是好的设计遵循了依赖倒转原则,代码更灵活

Honh has child:Dhris
Honh has child:Watt
4.注意事项


在具体开发中,应用依赖倒转原则(DIP)时需要注意以下几点:

  • 明确接口和实现之间的关系:确保接口定义了客户端代码所需的行为,而实现提供了这些行为的具体实现。
  • 使用抽象类或接口来定义抽象:避免使用具体类作为抽象,因为这会违反 DIP。
  • 通过依赖注入传递依赖项:使用依赖注入框架或手动将依赖项传递给客户端代码,而不是让客户端代码直接创建依赖项。
  • 避免循环依赖:确保依赖关系是单向的,即高层模块不依赖于低层模块,低层模块也不依赖于高层模块。
  • 考虑性能影响:在某些情况下,使用 DIP 可能会有轻微的性能开销,因此在应用 DIP 时需要权衡利弊。

5.最佳实践

DIP 有以下优点:

  • 提高代码的灵活性:通过使用抽象,我们可以轻松地更改具体实现,而无需修改客户端代码。
  • 提高代码的可测试性:通过使用抽象,我们可以对客户端代码进行单元测试,而无需依赖于具体实现。
  • 减少耦合:DIP 减少了客户端代码与具体实现之间的耦合,从而提高了代码的可维护性和可重用性。

6.总结

DIP 并不是万能的,在某些情况下可能会有一些局限性:
(1)轻微的性能开销:使用 DIP 可能会有轻微的性能开销,因为需要额外的开销来管理依赖项。
(2)过度抽象:过度抽象可能会使代码难以理解和维护。

过度抽象就会使得系统复杂化,不便于后续优化。

你可能感兴趣的:(CPP,设计模式,设计模式)