If you are going to extend a Class to use another instance of another interface, then ... yes ... you will need to change the Class: if you didn't how would the Class ever "know" about, or be able to use, the added interface ?
However an option would be extend some larger-scope entity that the Class inherits from ... or is injected an instance of an interface of.
For example, you could have an interface called ISamuraiGear that could include both Weapon and Dress. The Samurai class would then get an instance of that injected. So, you could extend WarriorGear without adding another interface.
But, at the point an instance of the Samurai class would want to use/invoke some Property/Method of its Dress instance, yes, obviously the instance of the Samurai class will have to be changed to explicitly use/invoke the Dress instance.
imho, the article you cite is a terrible example of DI, and you can find better explanations here on CodeProject: [
^].
My favorite explanation of DI is John Munsch's classic answer to the question "how do you explain dependency injection to a 5 year-old ?:"
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn't want you to have. You might even be looking for something we don't even have or which has expired.
What you should be doing is stating a need, "I need something to drink with lunch," and then we will make sure you have something when you sit down to eat.
[
^]. The link is to StackOverflow; and the text is also quoted in "Dependency Injection in .NET" by Mark Seemann (Manning Press, 2011), Ch. 1, p. 4.
In that book Seemann states: "Dependency Injection (DI) is a set of related patterns and principles. It’s a way to think about and design code more than it’s a specific technology. The ultimate purpose of using DI is to create maintainable software within the object-oriented paradigm. ... DI in isolation is just a small thing, but it’s closely interconnected with a large complex
of principles and patterns for object-oriented software design."