title: Java, Polymorphism, Static Typing and the "QueryInterface" pattern
body: <p>I'm working on an API design, and there's something about Java and polymorphism that I didn't think about until now. If I create an API like this:</p>
  
  <pre><code>interface FooFactory
  {
      public Foo getFoo();
  }
  
  interface Foo
  {
      public void sayFoo();
  }
  </code></pre>
  
  <p>then the only thing that my <code>FooFactory</code> implementation can be relied upon to provide is a <code>Foo</code> implementation. If I decide to provide some enhanced methods, like this:</p>
  
  <pre><code>interface EnhancedFoo extends Foo
  {
      public void patHeadAndRubBelly();
  }
  
  class EnhancedFooImpl implements EnhancedFoo
  {
      ... implementation here ...
  }
  
  class EnhancedFooFactoryImpl implements FooFactory
  {
      @Override public EnhancedFoo getFoo() { return new EnhancedFooImpl(); }
  }
  </code></pre>
  
  <p>and the only way my API clients can use the <code>EnhancedFoo</code> interface is if they obtain a <code>Foo</code> interface and try to cast it as the <code>EnhancedFoo</code>.</p>
  
  <p>I remember the way Microsoft handled COM in the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx" rel="nofollow"><code>IUnknown</code></a> interface:</p>
  
  <pre><code>HRESULT QueryInterface(
     [in]   REFIID riid,
     [out]  void **ppvObject
  );
  </code></pre>
  
  <p>The idea is that you pass in a GUID for the interface you want, if it succeeds, you get back a pointer that guarantees you can safely cast it to the interface you were looking for.</p>
  
  <p>I could do something similar in a typesafe way with Java:</p>
  
  <pre><code>interface FooFactory
  {
      public &lt;T extends Foo&gt; T getFoo(Class&lt;T&gt; fooClass);
  }
  </code></pre>
  
  <p>where I provide an implementation on request that either returns an instance of the desired subinterface, or returns null if none is available.</p>
  
  <p>My question, is:</p>
  
  <ul>
  <li>is the QueryInterface pattern reasonable?</li>
  <li>should I just use casting?</li>
  <li>or is the only right way to handle polymorphism in the API to restrict clients to strictly using the plain methods in question? (e.g. the methods in <code>Foo</code> in my example and not any <code>EnhancedFoo</code> methods)</li>
  </ul>
  
  <hr>
  
  <p><strong>Clarification:</strong> The factory implementation isn't going to be known by client code. (Let's say it uses dependency injection or some service provider architecture like java's <code>ServiceLoader</code> or NetBeans <code>Lookup</code>.) So as a client, I don't know what's available. The factory might have access to several <code>Foo</code> derivatives and I want the client to be able to request a feature set that it wants, and either it gets that, or it will have to fall back on the base <code>Foo</code> functionality. </p>
  
  <p>I guess the hard part for me is that there is runtime dependency here... the pure static typesafe approach where everything is fixed at compile time means that I can only depend on that basic <code>Foo</code> functionality. That approach is familiar to me, but then I lose out on possible enhanced features. Whereas the more dynamic / opportunistic approach is something that can take advantage of these features, but I'm not sure of the right way to architect a system that uses it.</p>