è 'protetto' sempre ragionevole al di fuori dei metodi e dei distruttori virtuali?

Sì.

Una situazione in cui un metodo protetto non virtuale ha senso potrebbe essere qualcosa come bool IsInitialized() . La classe è progettata per essere sottoclassificata. La sottoclasse potrebbe fornire nuovi metodi o metodi di sovrascrittura. In entrambi i casi, prima di poter eseguire questi metodi, è importante verificare che la classe sia inizializzata. Quindi il metodo IsInitialized () è fornito a tale scopo. È destinato ad essere utilizzato solo dai nuovi metodi di sovrascrittura nella sottoclasse e non dal codice chiamante. È anche previsto che IsInitialized () non venga sovrascritto. Il modo per fornire questo è dichiarando IsInitialized () per essere protetto e non virtuale.

Il punto di protected non è che i programmatori di estensioni siano più intelligenti dei programmatori di applicazioni e quindi ne sono consentiti di più. Non lo sono. Ce ne sono solo meno. Esistono argomenti validi per cui protected interrompe l'incapsulamento e, se possibile, dovrebbe essere evitato; ma il mondo non è perfetto, e l'incapsulamento perfetto non è un buon obiettivo, perché in pratica è in conflitto con troppi altri obiettivi validi. Pertanto ha ancora senso offrire agli autori di classe un mezzo per esporre le cose ad alcuni ma non a tutti gli altri. Essere un buon programmatore significa in gran parte essere in grado di prendere decisioni informate su tali trade-off.

Quando dichiari un membro della classe protected , ciò non significa che non vuoi che venga usato accidentalmente: è ciò che è per private . Dichiari membri protected quando hai dati o comportamenti utili per tutte le sottoclassi, ma non per gli utenti della classe.

Il modo più semplice per vederlo è esaminare il modello Metodo modello : la classe base espone un servizio che è utile al di fuori della classe e fornisce metodi protetti che le sottoclassi possono sovrascrivere per fornire comportamenti parziali al metodo template.

Il modello di metodo del modello utilizza metodi virtuali protetti in combinazione con uno pubblico non virtuale. La situazione può anche essere invertita: i metodi virtuali pubblici nelle classi derivate possono utilizzare un metodo non virtuale protetto nella classe base per fornire dati o comportamenti che dovrebbero essere protetti dagli utenti esterni alla classe base. In quasi tutte le situazioni in cui è coinvolto un membro protetto, ci sarà un membro virtuale associato da qualche parte lungo la catena di ereditarietà.

Pensa come se stessi sviluppando un'API. Ora devi pensare a come renderlo molto migliore in modo che gli utenti possano usarlo o usarlo con alcune personalizzazioni.

In un'API devi usare:

1. metodi pubblici: in modo che gli sviluppatori possano utilizzare le funzionalità fornite.
2. metodi privati: gli sviluppatori non si confondono o le interruzioni di api.
3. metodi protetti: in modo che se alcuni sono più intelligenti e vogliono estendere il codice che possono.

A volte durante la creazione di un'architettura / design del software è necessario nascondere alcuni interni dalle Classi dei chiamanti, ma questi sono necessari per le sottoclassi. Esempio (Java): Cosa succede se java.lang.Object cambia protected void finalize() accesso a public o private . Sicuramente questo creerebbe problemi.