This is the fifth day of my participation in the August More text Challenge. For details, see: August More Text Challenge

The dependency inversion principle contains the following three meanings:

  1. High-level modules should not depend on low-level modules; both should depend on their abstractionsCopy the code
  2. Abstractions should not depend on detailsCopy the code
  3. Details should depend on abstractionsCopy the code

It is interface-oriented programming. The dependency inversion principle can reduce the coupling between classes, improve the stability of the system, reduce the risks caused by parallel development, and improve the readability and maintainability of code.

For example, Xiao Ming drives a Mercedes.

We need two underlying modules, the driver class and the Mercedes class. And the high-level modules that call them both

It would normally look like this:

Cs: the Program.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class Program
    {
        static void Main(string[] args)
        {
            Driver driver = new Driver();
            Benzn benzn = newBenzn(); driver.drive(benzn); Console.ReadLine(); }}}Copy the code

Driver.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Dip
{
    class Driver
    {
        public void drive(Benzn benzn)
        {
            Console.WriteLine("I'm Xiao Ming the driver."); benzn.run(); }}}Copy the code

Benzn.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class Benzn
    {
        public void run()
        {
            Console.WriteLine("The Mercedes starts running..."); }}}Copy the code

The above code does the job.

But now I’ve bought another car, an Audi. Another driver xiao Wang was hired. The Driver module needs to be changed (to meet the requirement that Xiaoming can drive Mercedes and Audi). The Driver module needs to be changed (to meet the requirement that Xiaoming can drive Mercedes and Audi). There are too many things to change. Unreasonable structure design.

Now let’s design the program according to the principle of dependency inversion (interface oriented programming) :

Define a driver interface and a car interface.

IDriver:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    interface IDriver
    {
        void drive(ICar car); }}Copy the code

ICar.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    interface ICar
    {
        void run(); }}Copy the code

Program.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class Program
    {
        static void Main(string[] args)
        {
            IDriver driver = new Driver();
            ICar benzn = newBenzn(); driver.drive(benzn); Console.ReadLine(); }}}Copy the code

Benzn.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class Benzn:ICar
    {
        public void run()
        {
            Console.WriteLine("The Mercedes starts running..."); }}}Copy the code

IDriver.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class Driver:IDriver
    {
        public void drive(ICar car)
        {
            Console.WriteLine("I'm Xiao Ming the driver."); car.run(); }}}Copy the code

DriverNew.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class DriverNew:IDriver
    {
        public void drive(ICar car)
        {
            Console.WriteLine("I'm xiao Wang the driver."); car.run(); }}}Copy the code

Aodi.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dip
{
    class Aodi:ICar
    {
        public void run()
        {
            Console.WriteLine("The Audi starts running..."); }}}Copy the code

This design of program structure has an advantage, that is, new cars and drivers do not need to change the underlying module Driver, as long as a new underlying module class is good, modify the high-level module (business scenario class), can reduce the risk of “change” to the minimum.

Abstraction is the implementation constraints, is to rely on a contract, discipline yourself, not just also discipline yourself with external relations at the same time, its purpose is to ensure that all the details is not out of the category of contract, to ensure that the constraints, the two sides in accordance with the relevant provisions (abstract) the common development of a good contract, as long as the abstraction of the line is still there, detail is out of this circle. Just like a basketball game, the rules have been set, if you play according to the rules, then it will be fun. But if people get out of the rules, then maybe the game won’t go well.

Deep understanding of

The essence of dependency inversion principle is to make each class or module realize independent of each other through abstraction (abstract class or interface), do not affect each other, and realize loose coupling between modules. Using this rule in a project requires the following principles; Each class should have interface or abstract class as far as possible, or abstract classes and interfaces are: the basic requirement of the dependency inversion principle, have the abstract as far as possible to the surface of the dependency inversion variable type is the interface or an abstract class Should not be any class derived from the specific class Try not to rewrite the base class has written method (the substitution principle) in the combined type substitution principle to use: In combination with the substitution principle and dependency inversion principle, we may draw a popular rule, interface is responsible for defining the public attributes and methods, and statement of dependencies with other objects, the realization of the abstract class is responsible for the public construction part, the implementation class accurately implement the business logic, and at the appropriate time to refine the parent class.

For good suggestions, please enter your comments below. Welcome to guanchao.site

Welcome to applet: