Change dependency injection to dependency inversion

[ghost]

On page 6,

We’ve extracted the charging logic into the Payments interface—in essence employing dependency injection.

I believe dependency inversion would be more a accurate term here.

You improved the domain modelling of the program by no longer having a credit card charge itself (no idea why it was doing this in the first place) and then having a payment processor doing it instead. You then used a trait for the payment processor instead of a concrete implementation for the sake of dependency inversion, which you achieve through dependency injection...however you don't have any more dependency injection than you had before and you could've made CreditCard a trait as well with a concrete SimulatedCreditCard class and achieved the same result. So adding the payment processor didn't change anything except model your domain better and the dependency injection that you already had simply allowed you to achieve dependency inversion by depending on a trait rather than a concrete implementation.