I linguaggi OOP dovrebbero eliminare la parola chiave 'protetta' per costringere i programmatori a scrivere codici puliti e di alta qualità?

Si tratta di evitare il rumore e mantenere il raggio d'azione stretto. L'unico modo per i discendenti di accedere ai membri principali sarebbe quello di rendere questi membri accessibili pubblicamente, il che esporrebbe tali membri ai clienti (utenti della classe). Questo potrebbe non essere utile, sconcertante e pericoloso. Sicuramente non sarebbe pulito. Littering sarebbe la parola, dovresti letteralmente sparpagliare le funzionalità interne delle classi su tutti i tuoi spazi dei nomi. Sarebbe così disordinato.

Questi consigli sono solo contro i campi protetti. Avresti ancora bisogno di protected per i metodi. È collegato al consiglio comune contro i campi pubblici. In effetti, stanno discutendo i campi dovrebbero sempre essere privati e solo esposti attraverso getter / setter.

In generale è un consiglio ragionevole, ma a volte un campo pubblico o protetto è l'approccio più semplice e diretto, e l'aggiunta di getter / setter sarebbe inutile, quindi non mi piacerebbe che fosse imposta dal compilatore. Tutto dipende dal contesto.

L'ereditarietà soffre di numerosi problemi, come il fragile problema della classe base, creando un accoppiamento stretto, bidirezionale e un incapsulamento indebolente. Inoltre, può rendere i test più difficili di quanto non sia necessario. (Vedi Ereditarietà: smetti di usarlo già! per dettagli di tutto quanto sopra [disclaimer: scritto da me]).

Non ci sono casi d'uso che sono stato in grado di trovare dove l'ereditarietà funziona meglio dell'uso di una combinazione di progettazione per interfacce e utilizzo della composizione.

C'è quindi un buon motivo per cui le lingue moderne non supportano affatto l'ereditarietà. Tuttavia, se lo supportano, allora protected rimane necessario. Senza di esso, la gente userebbe ancora l'ereditarietà, ma sarebbe costretta a indebolire ulteriormente il loro incapsulamento rendendo quei membri sovrascritti dalle sottoclassi, public . E la semplice rimozione dell'eredità dalle lingue esistenti potrebbe spezzare il codice esistente, quindi sfortunatamente è anche un antipasto.