Yes, but only if you need it.
The Dependency Inversion Principle is not about making something work now.
It talks about abstractions and concretions but it's not really about that either.
It's about change.
I can make anything work without DIP. Seriously, there isn't a single program in existence that can't be written completely DIP free.
We don't use DIP to accomplish a requirement. We use DIP so that the inevitable new requirement doesn't force a massive rewrite, recompilation, and redistribution.
So, do you need DIP here?
Well there isn't much code here to go by, other than it's clear that
ShowUserInfo knows about
User. The question then is if we care.
Think about this:
User knows about
String is as concrete as they come. Yet no one ever throws DIP at
String. Why? Because
String is stable (unlikely to change). Can you say the same thing about
User is volatile (likely to change) then it's dangerous for
ShowUserInfo to know about it directly. A change to
User requires a change to
ShowUserInfo if there is no DIP. A more stable interface or purely abstract class (doesn't matter which) helps protect against this volatility.
Now that's just about needing a more stable abstraction. DIP can actually do a little more for you.
DIP lets the flow of control go against the source code dependency. That gives you even more options to isolate against change.
DisplayUserInfo which do you think is more stable?
The usual pattern is to assume the business rule classes are the most stable and the reporting / adapting classes that communicate with the outside world are less so. But, if for some reason you thought
User was less stable you could use DIP to reverse the source code dependency so that
DisplayUserInfo knows nothing about
User and so is protected from its volatility. It's better to know about stable things than unstable things. What you don't know about can't hurt you.
That's the real nifty thing about those open arrows <|-- you see in UML diagrams. Flow of control goes through them backwards. That inversion of direction is where this principle gets its name.
Since DIP lets you replace a uses arrow --> with an implements arrow <|-- pointing the other way, you get to decide what knows about what regardless of what needs to talk to what. That's the real power of DIP.