È una violazione del principio Open-Closed aggiornare una costante che rappresenta un valore reale?

Ho una classe che calcola il reddito annuo netto dei lavoratori. Ha una costante che rappresenta una percentuale fiscale. Ma un giorno l'aliquota fiscale è cambiata, quindi devo correggere il codice.

L'atto di fissare questa costante indica una violazione del principio aperto-chiuso , poiché postula che una classe dovrebbe essere chiusa alla modifica?

L'OCP può essere meglio compreso quando si pensa a classi o componenti forniti da un fornitore A in una sorta di libreria a scatola nera, per l'utilizzo da parte degli utenti B, C e D (si noti che questo è solo un modello mentale che sto usando per chiarezza, non importa se in realtà l'unico utente della classe è A stesso).

Se B, C e D possono utilizzare o riutilizzare le classi fornite per diversi casi d'uso, senza la necessità di modificare il codice sorgente della libreria, il componente soddisfa l'OCP ( rispetto a una categoria di casi d'uso ). Ci sono diversi modi per raggiungere questo obiettivo, come

• rendere ereditaria la classe (in genere in combinazione con il modello di metodo del modello o il modello di strategia)

• fornendo "punti di iniezione" per l'iniezione di dipendenza

• fornendo i parametri di configurazione per la classe o il componente (ad esempio, avendo un parametro costruttore "percentuale fiscale", come nel tuo caso, o usando qualche altro meccanismo di configurazione)

• forse altri mezzi, a seconda del linguaggio di programmazione o dell'ecosistema

Gli esempi tipici che trovi nei libri di testo sono spesso di primo o secondo tipo (immagino perché agli occhi degli autori di quel libro, il terzo tipo è troppo banale per essere menzionato).

Come vedi, questo non ha nulla a che fare con la proibizione di qualsiasi modifica del codice sorgente da parte del fornitore A (come per la correzione di bug, l'ottimizzazione o l'aggiunta di nuove funzionalità in modo compatibile con le versioni precedenti), che non è affatto correlato all'OCP. L'OCP riguarda il modo in cui A progetta l'interfaccia e la granularità dei componenti nella libreria, quindi diversi scenari di riutilizzo (come il resuage con aliquote fiscali diverse) non inducono automaticamente i requisiti per il cambiamento.

Quindi, nonostante ciò che gli altri ti dicono qui, la risposta è chiaramente "sì" , sarebbe una violazione dell'OCP.

EDIT: sembra che qualcuno abbia scritto un post dettagliato sul blog sull'esatto argomento. Sebbene parti di esso possano essere state formulate meglio (come sottolineato da Derek Elkins), sembra che l'autore generalmente condivida il mio punto di vista sul fatto che "soddisfare l'OCP" non è una proprietà assoluta, ma qualcosa che può essere valutato solo nel contesto di alcuni categorie di modifiche ai requisiti.

Come altri stanno dicendo, idealmente la classe di reddito del lavoratore consentirebbe la parametrizzazione della costante, rendendo questa classe indipendente da quel valore.

In definitiva, l'applicazione chiamante potrebbe anche consentire la parametrizzazione in termini di configurazione esterna (ad esempio un file). Una volta che abbiamo una configurazione esterna, possiamo modificare l'aliquota fiscale, anche se considera che se il file di configurazione viene letto solo una volta all'avvio, l'applicazione dovrà essere riavviata per rendere effettive le percentuali fiscali aggiornate, quindi è qualcosa da mantenere mente. Potremmo fornire una funzione applicativa per rileggere la configurazione quando richiesto per farlo, oppure potremmo fornire un meccanismo più complicato che rileva quando il file di configurazione cambia ...

A lungo termine, potresti scoprire che i problemi fiscali richiedono più di una semplice percentuale, ad esempio che un giorno le leggi fiscali sono più complesse e richiedono diverse percentuali e alcune costanti (ad esempio l'importo inferiore a $ 10k tassato all'X%, mentre il resto tassato all'Y%).

Ciò suggerisce fondamentalmente l'utilizzo di un modello di strategia, in cui la classe principale in questione qui accetta un oggetto di strategia per il calcolo dell'imposta.

Le varie strategie (e% 's e $ costanti) dovrebbero essere selezionabili dal file di configurazione, e ora, l'aggiunta di una nuova strategia richiede l'aggiunta di un nuovo codice, ma non necessariamente gli aggiornamenti al codice esistente.

Ogni strategia potrebbe sapere come analizzare / interpretare i propri argomenti di configurazione esterni, insieme a come calcolare l'imposta effettiva.

Dinamicamente, l'imposta può dipendere ulteriormente dalle impostazioni internazionali, pertanto è possibile che le impostazioni locali siano associate agli utili o ai dipendenti (o entrambi). Nella configurazione esterna, potremmo associare le impostazioni locali alla strategia fiscale.

Vedi anche l' iniezione delle dipendenze , dove gestiamo queste cose in modo esplicito.

Se è necessario modificare la classe per modificare il valore fiscale, il suo design sta effettivamente violando OCP. Il design appropriato, per quello che hai descritto finora, è che la classe calcolatrice prenda il valore fiscale come parametro.

Se la tua classe è istanziata (nel senso che non è una classe statica), rendendo la proprietà della classe variabile fiscale, il cui valore viene iniettato attraverso il costruttore, migliorerai anche la coesione della classe.

In breve, il tuo progetto attuale fa sì che la tua classe dipenda da un valore costante che non è in realtà una costante (che definisce la costante come un valore che non cambierebbe mai, come il valore di PI). Viola OCP. Modificare il progetto per ricevere il valore fiscale come argomento del costruttore.

Totalmente d'accordo con @Becuzz, e voglio solo riassumere questo: OCP riguarda la ricerca di astrazioni riutilizzate (quindi utili) che vengono iniettate in una classe. Quindi il comportamento della classe viene modificato non cambiando il suo codice, ma fornendo diverse implementazioni. Ciò è chiarissimo nel libro di Robert Martin " Sviluppo software agile, principi, schemi e pratiche ", controlla il capitolo corrispondente "Il principio aperto-chiuso", sotto-capitolo "L'astrazione è la chiave". Chiarisce un altro malinteso secondo cui il comportamento può essere modificato solo con l'eredità. Fu Bertrand Meyer a proporlo nel 1988 nel suo libro " Object Oriented Software Construction ", non Robert Martin.

Per come la vedo io non è una violazione del principio aperto chiuso. Tuttavia, il fatto che qualcosa che è destinato a cambiare nel tempo (come la percentuale fiscale) è una costante è un difetto di progettazione: non si deve cambiare il valore della costante ma come si gestisce la percentuale fiscale. Questo dovrebbe essere un tipo di impostazione che potrebbe essere modificata senza ricompilare il tutto.