@Zest4Quest: I agree with what @weberse has posted. For an article on resolving overrides see Resolving Objects by Using Overrides.
In general, the factory pattern addresses the issue you are mentioning but I do understand your concern about the seemingly unending proliferation of factories this might cause. I think part of the reason might be the example -- it's a little contrived
so it's hard to tell the best design.
name and age sound like Value Objects whereas IComponent sounds like a service. Or put another way: name and age are part of the application data which is not known at design time whereas IComponent is one of a known set of services. If
that is the case it might make sense to inject IComponent but have name and age be part of method data.
For example if you had a class Authenticator it might take constructor parameters of type ILogger and IAuthenticationProvider -- these would be injected services. But you wouldn't inject username and password, you would just pass those into a method
call such as Authenticate(username, password). (Well, you would probably have a more generic method signature to account for different authentication schemes besides username/password but you get the idea. :) )
Not to say that there are not any scenarios for using overrides, just some thoughts.
Enterprise Library support engineer