Critica del modello di progettazione della composizione che richiede classe derivata

Question

Critica del modello di progettazione della composizione che richiede classe derivata

#1 da (1 voti)

3

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?

interfaces design-patterns inheritance

posta Ryan 22.02.2017 - 22:00

fonte

1 risposta

Leggi altre domande sui tag interfaces design-patterns inheritance

Raggruppamento di punti che riduce al minimo la distanza media complessiva dal centro indicato Il modo migliore per gestire le variabili dev / test / prod in Python?

score 1 · Answer 1

Il problema principale qui è che non hai alcuna interfaccia. Se dovessi aggiungere un'interfaccia IAppQueryBuilder penso che risolverebbe la tua preoccupazione, e renderà anche molto più semplice i tuoi tester dell'unità, che saranno in grado di sostituire uno stub invece di prendere in giro l'istanza concreta.