Did I understand the principle of dependency inversion correctly?

Question

Java

There is an interface

public interface INumberOperation {
    public void executeOperation (int number);
}

This interface implements several classes that perform various operations.

public class NumberOperation1 implements INumberOperation{
    @Override
    public void executeOperation(int number) {
        number += number * 2;
        System.out.println(number);
    }
}

public class NumberOperation2 implements INumberOperation{
    @Override
    public void executeOperation(int number) {
        number += 100;
        System.out.println(number);
    }
}

And it is executed in the main class.

public class Main  {
    public static void main(String[] args) {
        INumberOperation iNumberOperation;
        iNumberOperation = new NumberOperation1();
        iNumberOperation.executeOperation(100);
        iNumberOperation = new NumberOperation2();
        iNumberOperation.executeOperation(100);
    }
}

That is, I am not dependent on a specific class that performs a specific task.
If I understand the implementation of dependency inversion correctly, how does it differ from the strategy pattern?

Answer 1

The main idea behind the Dependency Inversion Principle is "Details depend on abstractions, but not abstractions depend on details".
In your example, the Main class depends on everything: the INumberOperation interface and both the NumberOperation1, NumberOperation2 classes. That is, the principle of dependency inversion does not work here at all. No way.
It appears in the following example. Let me have some abstract logic "read a number, perform an operation on it, write down the result". This abstract logic (that's why it is abstract) should not know anything from where it reads the number, what operation it performs on it, or where and how it writes the result. Thus, we have a module consisting of

interface NumberInput {
  int read();
}
interface NumberProcessor {
  int process(int a);
}
interface NumberOutput {
  void write(int a);
}
class Processor {
  private final NumberInput input;  
  private final NumberProcessor processor;
  private final NumberOutput output;

  public Processor(NumberInput input, NumberProcessor processor, NumberOutput output) {
    this.input = input;
    this.processor = processor;
    this.output = output;
  }

  void process() {
    output.write(processor.process(input.read()));
  }
}

All. The module turned out to be very abstract and does not depend on anyone.
Then we can make implementations of these interfaces - they will depend on our logic module (since interfaces are referenced). And this is fully consistent with the principle of dependency inversion - details depend on abstractions.
And finally, the main function, which will collect all this into a single whole. It is the most concrete thing in our program, since it deals with the concrete classes that it instantiates. Therefore, it depends on all modules - on the abstract logic module and on modules with interface implementations. And here the principle of dependency inversion is also observed - the detail (in which configuration the program is launched) depends on abstraction (abstract logic and specific implementations of interfaces from which the one that will be used is selected)
This principle is very well explained in R. Martin's book "Clean Architecture At least everything fell into place for me after reading this book.

Answer 2

Watch Alexander Byndyu's video at this link: https://blog.byndyu.ru/2013/06/blog-post_27.html (This is C#, but in general it is very similar to Java, so it should be perceived normally) He expands the example there very well. After watching this video, you start to look at the code in a new way.