Caso di ereditare una classe non banale?

Question

Stavo leggendo la parola chiave sigillata in C #. Non ricordo l'ultima volta che eredito da una libreria standard. In c ++ ricordo di aver ereditato un'interfaccia std che digitava alcuni tipi e utilizzava alcuni dei miei parametri. Ma questo è 1) Trivial 2) Un'interfaccia

Dall'alto della mia testa, non ricordo alcuna classe che ho ereditato che non avesse una funzione virtuale che si aspettava di essere ereditata. Qualcuno può dirmi di una situazione in cui era necessario ereditare una classe non banale che non era un'interfaccia?

Potrei anche dire che è una buona regola usare il pollice per non ereditare una classe a meno che non abbia funzioni virtuali. È una buona regola empirica?

NOTA: utilizzo l'operatore SomeClass & amp; SomeClass () {return m_someClass; } nel caso in cui ho bisogno di passare il mio oggetto come un'altra classe. Funziona bene.

Answer 1

In realtà è usato in C ++, per tutti questi tipi di eredità non-is-a (es. ereditare un'implementazione, mixins, boost :: noncopyable, dove erediti da essa e rendi la tua classe non copiabile, boost :: operatori dove erediti da una classe e questo aggiungerà alcuni operatori alla tua classe). Inoltre, quando si esegue la metaprogrammazione con tipi C ++, ereditare da un altro tipo (i) è uno dei metodi più semplici per comporre i tipi.

Un altro caso in cui erediti da una classe che non ha funzioni virtuali, ma funge da "tipo di" un'interfaccia, è polimorfismo statico (tecniche come CRTP, dove classe ConcreteA: BaseA). Non hanno bisogno delle funzioni virtuali, perché tutto viene risolto in fase di compilazione.

Tuttavia, se vuoi trattare la tua runtime in modo polimorfico, dovresti davvero rendere virtuale almeno un metodo, e quello sarebbe il distruttore. Ci sono eccezioni, ma rare.

Anche quando hai una gerarchia polimorfica, a volte derivi da classi concrete. Un esempio potrebbe essere una SingleLineEdit derivante da TextEdit. Tuttavia, questo è un po 'pericoloso, perché interrompe l'incapsulamento della classe genitore (ad es. I suoi metodi possono prevedere alcuni dettagli di implementazione, e devi rispettarli e conservarli nella sottoclasse - il che può essere complicato, dal momento che sono dettagli di implementazione che possono cambiare senza preavviso nella prossima versione ecc.)

Answer 2

Direi che il concetto chiave della programmazione orientata agli oggetti è il polimorfismo. Se ereditare da una determinata classe non ti consente di trarre vantaggio dal polimorfismo, allora che senso ha ereditare? Quindi, se non ci sono metodi da sovrascrivere, non effettuare la sottoclasse. Aumenteresti solo la complessità del tuo codice. Se desideri molte delle stesse funzionalità, inserisci semplicemente la classe esistente nella tua.