Critique of composition design pattern requiring derived class

Question

I have the following two inheritance chains:

 BaseQueryBuilder          BaseApplication
       |                          |
       |                          |
  AppQueryBuilder            Application

BaseQueryBuilder is an abstract class, which AppQueryBuilder extends by adding additional query builder methods that are specific to the application. BaseApplication is interface that Application implements. I'm using composition to merge the to, so the constructor for Application looks something like the following:

class Application(AppQueryBuilder queryBuilder) {
    _queryBuilder = queryBuilder;
}

Note that other functions in Application depend on the existence of methods in AppQueryBuilder that are not defined in BaseQueryBuilder, but rather added in the definition of AppQueryBuilder.

Question: Is this poor style? I'm a bit uneasy about the fact that Application's constructor requires a concrete implementation, named AppQueryBuilder, rather than accepting its parent interface (though this is not possible, as I've described above). Is there a cleaner, obvious alternative design pattern that I should be using?

Answer 1

The main issue here is that you don't have any interfaces. If you were to add a IAppQueryBuilder interface I think it would address your concern, and also make it much easier on your unit testers, who will be able to substitute a stub instead of mocking the concrete instance.