title: Constructor injection with non-dependency parameters
body: <p>I have an interface <code>ITradingApi</code> like so:</p>
  
  <pre><code>public interface ITradingApi
  {
      IOrder CreateOrder(...);
      IEnumerable&lt;Symbol&gt; GetAllSymbols();
      // ...
  }
  </code></pre>
  
  <p>This is meant to be a facade for the different APIs of the vendors of trading software.
  My view model has a dependency on this trading API in its constructor:</p>
  
  <pre><code>public class MainViewModel
  {
      public MainViewModel(ITradingApi tradingApi) { /* ... */ }
      // ...
  }
  </code></pre>
  
  <p>I use Ninject as an IoC container, so I will create an instance of my view model like this:</p>
  
  <pre><code>var vm = kernel.Get&lt;MainViewModel&gt;();
  </code></pre>
  
  <p>Now, my problem:</p>
  
  <p>The implementation of <code>ITradingApi</code> might need additional parameters to work.<br>
  Example:  </p>
  
  <ul>
  <li>One vendors API uses TCP/IP internally, so I need a hostname and a port.  </li>
  <li>Another vendor uses a COM object. Here I don't need any info.  </li>
  <li>A third vendor needs username and password of the account.</li>
  </ul>
  
  <p>In the spirit of not allowing incomplete objects, I added these as parameters to the constructors of the concrete implementations.</p>
  
  <p>Now, I am not sure, how this would work. Clearly, these additional parameters do not belong into the interface, because they are specific to each implementation.<br>
  On the other hand, these additional parameters need to be entered by the end-user and then passed to the implementation of <code>ITradingApi</code>, meaning that the user of <code>ITradingApi</code> needs intimate knowledge about the concrete implementation.<br>
  How to solve this dilemma?</p>
  
  <p><strong>UPDATE:</strong><br>
  One approach could be to create an <code>ITradingApiProvider</code> that exposes a list of required parameters. The View could automatically create an input form for these parameters that is databound to the parameters in <code>ITradingApiProvider</code>. Now, when an <code>ITradingApi</code> instance is requested from the provider, it can make use of these parameters to create an instance of the concrete implementation. Clearly the implementation of <code>ITradingApiProvider</code> and <code>ITradingApi</code> are tightly coupled, but I think that is not a problem as long as each implementation of <code>ITradingApi</code> comes with a corresponding implementation of <code>ITradingApiProvider</code>.</p>