Come motivare i modificatori di accesso di classe mutevoli adattivi

1

Al nuovo cliente, abbiamo discusso dei modificatori di accesso per classi, metodi, membri, ecc. Un parere era di mantenere le cose il più private possibile, consentendo solo il livello protetto (interno, pubblico) quando necessario. L'opinione opposta era quella di "lasciar fluire le cose" e applicare il livello di accesso pubblico in tutte le classi (o almeno nella maggior parte delle classi).

L'argomento del primo è di prevenire il maltrattamento da parte di sviluppatori malintenzionati e / o ignoranti. Inoltre, una precauzione generale just-in-case.

L'argomento di quest'ultimo è la facilità di utilizzo basata sulla fiducia per le capacità e le intenzioni degli altri sviluppatori.

Le classi in questo caso particolare saranno utilizzate internamente all'interno dell'azienda (o forse ancora più limitatamente, all'interno della divisione o del team). Tuttavia, è interessante se questo è un argomento sufficientemente strong da sostenere omettendo il solito approccio di accessibilità meno necessaria.

Senza difendere una visione o l'altra (anche se ho un'opinione strong e chiara sull'argomento), mi piacerebbe ricevere feedback da altri sviluppatori in questa materia. (L'esperienza e il livello di efficienza della squadra, sono lasciati intenzionalmente, poiché considero tecnicamente competenti tutti i nostri membri).

Quando mi rendo conto che potrebbe non essere chiaro quale sia la situazione di cui sto parlando, vorrei sottolineare quanto segue. Uno dei membri del team ha sollevato il punto che in determinate circostanze , come compagni di squadra fidati e qualificati, utilizzo localizzato, casi d'uso responsabili e competenti ecc., Non c'è alcun vantaggio nel seguire la convenzione, mentre lo svantaggio è il contenimento della produttività. Nelle condizioni a cui si riferiva il membro, non c'è alcun guadagno da recuperare seguendo il disaccoppiamento, SOLID ecc. Tuttavia, mi chiedo se questo sia un argomento sufficientemente strong per consentire l'omissione dei principi di progettazione (in questi casi) o se dovremmo rispettare le convenzioni in qualsiasi circostanza, per ogni evenienza.

    
posta Konrad Viltersten 01.04.2016 - 13:28
fonte

1 risposta

8

È una falsa pista per trasformarlo in una questione di "fiducia" o "competenza". I modificatori di accesso sono una questione di incapsulamento e l'incapsulamento è uno strumento per gestire la complessità. Vuoi l'incapsulamento indipendentemente dal livello di abilità degli sviluppatori.

Non è che ci sia un certo livello di abilità al di sopra del quale non è necessario utilizzare buone pratiche di sviluppo come incapsulamento, separazione delle preoccupazioni e via. Piuttosto è il contrario, gli esperti sviluppatori sanno come usare questi principi, ed è per questo che sono più produttivi dei novizi.

Nota: se hai sviluppatori maliziosi , sei in grossi guai e nessuna modifica dei modificatori di accesso ti sarà di aiuto. I modificatori di accesso non sono una misura di sicurezza. In linguaggi come Java o C # è comunque possibile chiamare metodi privati tramite reflection, e in Python non è altro che una convenzione di denominazione.

    
risposta data 01.04.2016 - 14:28
fonte

Leggi altre domande sui tag