No, I don't think it is a good example (at least not how it is implemented here). Let me explain why.
First, you get rid of the dependency
Printer - that is fine. The standard approach would be to introduce an interface
IPrinter, but in this case, an even simpler solution is possible.
The code already shows how this can be accomplished:
salariesHandler.GetSalary(salaryID) provides a
Salary object, which has an
AsPrintable() method, which delivers something a
Printer can process. In case the method
PrintSalary would be placed on a higher level like a controller class, both existing classes are already decoupled, they can be used and tested on their own, and maybe placed in separated black-box libraries.
PrintSalary is misplaced inside the
Printer object, it depends on
SalariesHandlerFactory, which depends on all concrete derivations of
ISalariesHandler. By calling
GetInstance() directly inside
Printer (instead of using something like constructor injection),
Printer becomes dependent on all those derivations, too, for no apparent reason. Note that, even if constructor injection would have been used, it is pretty mystical what purpose the factory has, since all dependencies were already eliminated at that time.
The point of the DIP is to make "high level modules" (like
SalariesHandler) not depend on "low level modules" like
Printer. But that does not mean to make "low level modules depend on high level modules", that's a misconception probably caused by taking the word "inversion" too literally. It means to make both the low level and high level modules depend on abstractions (see Wikipedia, they use exactly this wording). Here, the abstraction on which
Printer could both depend is something general which can be printed - for example, a format string, an html string, a list or table of strings, an abstract
IReportPage object, whatever
"Dependency inversion" is not an end in itself, it is a means to an end. Don't forget about the actual goal, which is usually easier reusage and testing. When the same goal can be accomplished by simpler means and "Dependency elimination" instead of "inversion", there is no need to artificially introduce an additional "inverted dependency" again.