2012-10-16 22 views
5

Ho una domanda su un codice che ho recentemente preso tra le mani. Voglio solo sapere se in C++ template paradigma è corretto o utile per effettuare le seguenti eredità (solo 3 classi come esempio):Ereditarietà da un modello C++


template< class I, class P, class D, unsigned int ID = 0 > 
class PathFilter : public Filter< I, P, 1 > 
{ 
... 
} 

template< class I, class A, unsigned int N = 1 > 
class Filter : public Algorithm< I, A > 
{ 
... 
} 

template< class I, class A > 
class Algorithm : public A //This line 
{ 
    ... 
} 

La mia domanda riguarda specificamente l'ereditarietà nel terzo esempio. È utile renderlo così "generico" e non preciso? È una buona scelta per compromettere il codice comprensibile con un codice più generico?

Chiedo innanzitutto perché non sono un esperto di modelli C++, ma anche perché vedo questo codice difficile da capire usando i modelli (di solito i nomi dei modelli non dicono nulla sul suo contenuto). Qualche consiglio?

risposta

2

Quello che stai facendo è un mixin classe (in particolare, la tua classe Algorithm è quella).

Come riferimento è possibile consultare, ad esempio, http://en.wikipedia.org/wiki/Mixin o http://en.wikipedia.org/wiki/Composite_pattern.

In effetti si specifica "determinate funzionalità (specificate da A) da ereditare o semplicemente riutilizzate da una sottoclasse (ad esempio Algorithm)". (cit dal primo articolo)

In altre parole, stai rendendo te stesso (o il tuo utente) libero di aggiungere o modificare il comportamento a Algorithm in qualche modo "dopo". Il tuo reale vantaggio è di ottenere una tale flessibilità basandosi solo sul compilatore e non su un meccanismo di tipo dinamic-binding (ad esempio, l'override delle funzioni virtuali). La classe finale Algorithm<A>, infatti, è costruito al momento della compilazione ed è forse efficiente come la classe che avrebbe ottenuto la scrittura Algorithm<A> esplicitamente (vale a dire in modo esplicito compresa la politica A in Algorithm scriverlo a mano).

EDIT:

Vorrei anche suggerire di dare un'occhiata a questa pagina di wikipedia sulla struttura basata su regole (http://en.wikipedia.org/wiki/Policy-based_design).

Qui, i nomi dei criteri (il tuo A) appaiono in una forma chiara, con nomi chiari, come saggiamente consigliato da @ full.stack.ex.

+1

Quindi, se è quello che vuoi, va bene. Per quanto riguarda la leggibilità, è vero, esiste una tradizione di denominare i parametri del modello in modo strano: I, P, A, ecc. Ma non è necessario :). Dai loro nomi migliori e potrebbero diventare auto-descrittivi. –

+1

Grazie per la risposta, ma ho ancora una domanda. Comprendo l'uso di una definizione generale e astratta di alcune funzionalità in una classe "superiore". Ma l'obiettivo principale di un modello non è quello di generalizzare i tipi di parametri? Quindi quello che sto dicendo alla fine è che posso passare quasi tutto a questa classe superiore e conservare le funzioni di una gerarchia inferiore. Alla fine avrò un insieme molto ristretto di oggetti che possono ereditare (forse uno) le funzioni inferiori, sbaglio? Non è un modo poco pratico per definire questa genericità? –