Dependency Inversion Principle – Understanding Low and High Level Components

What he's saying here is that you should avoid a scenario where a base class takes a dependency to meet the need of a descendant. Let's look at the case of a Switch and its descendant the TimedSwitch. The TimedSwitch is a Switch that resets itself after a certain amount of time. We have the TimedObject class already so it would make sense for TimedSwitch to derive from it...however TimedSwitch already derives from Switch. So in order to meet the needs of the TimedSwitch, Switch will inherit from TimedObject even though it doesn't need that functionality itself.

The Switch (abstraction) is dependent on the details of TimedSwitch. To fix this violation of the DIP, we have TimedSwitch implement ITimedObject and delegate to a contained TimedObject class (prefer composition over inheritance).

Another more generic example is the layered approach. The higher level layers are abstractions and in most cases they depend on the details. DIP says that instead, the lower layers should conform to an interface which they both take dependency on. Thus the dependency is inverted from Higher Layer depending on lower layer to both layers depending on an interface.

Depend on abstractions, not on concretions It means, coding to interfaces, not to concrete classes?

For languages that support interfaces, this is generally the case. But that abstraction layer can be provided via other means, such as an abstract class, a factory, reflection etc. The important thing is that you do not directly couple a requirement to a named, concrete, class.

*Why Spring bean example is given? Yes we can use interfaces to inject the dependency. But, we can also inject a concrete class?

Presumably, because you are looking at "SOLID Principles in Java" (emphasis mine). Spring is a popular DI framework for Java. "But, we can also inject a concrete class?" You always inject a concrete class. But which concrete class is determined by your spring configuration. The receiver of the injection only depends on an abstraction, not that specific class. Having something else tell it what concrete implementation it is to use is the essence of DI.