Critica del modello di progettazione della composizione che richiede classe derivata

Ho le seguenti due catene di ereditarietà:

 BaseQueryBuilder          BaseApplication
       |                          |
       |                          |
  AppQueryBuilder            Application

BaseQueryBuilder è una classe astratta, che AppQueryBuilder estende aggiungendo metodi di builder di query aggiuntivi specifici dell'applicazione. BaseApplication è l'interfaccia che Application implementa. Sto usando la composizione per unire il to, quindi il costruttore per Application ha un aspetto simile al seguente:

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

Si noti che altre funzioni in Application dipendono dall'esistenza di metodi in AppQueryBuilder che sono non definiti in BaseQueryBuilder , ma piuttosto aggiunti nella definizione di AppQueryBuilder .

Domanda : questo stile è mediocre? Sono un po 'a disagio sul fatto che il costruttore di Application richieda un'implementazione concreta, chiamata AppQueryBuilder , piuttosto che accettare la sua interfaccia genitore (sebbene ciò non sia possibile, come ho descritto sopra). Esiste un modello di progettazione alternativa più pulito e ovvio che dovrei usare?