Non sto ancora lavorando, sto solo studiando e di recente ho a che fare con i principi SOLID. Ho letto molto sul principio di open closed ma sfortunatamente la maggior parte dei libri e degli articoli condividono gli stessi esempi. Non capisco quanto segue: se la classe non deve essere modificata dopo che è stata
But it does not address the issue if the base class implementation needs to change (for example a method that is implemented at the base class level). Why this principle does not address that?
Il punto di tenerlo aperto all'estensione è evitare di dover apportare tale modifica diretta.
La modifica diretta è sempre possibile ma può comportare costi significativi. L'OCP ti chiede di iniziare con un progetto che, si spera, eviti la necessità di modifiche dirette, ed è un costo, poiché i requisiti cambiano.
Un design che consente una sostituzione polimorfica del comportamento offensivo significa che non è necessario toccare il codice che si desidera modificare. Devi solo scrivere un nuovo codice.
Ciò significa che se trovi che DEVI cambiare l'implementazione della classe base, hai già fallito nel seguire l'OCP. Dovresti aver usato un design che avrebbe permesso che quell'implementazione fosse sostituita con un altro codice scritto da qualche altra parte.
Ci sono molti modi per farlo. Il polimorfismo si presenta in molte forme. Ereditarietà, composizione e delega, wrapper, si va avanti e avanti. Ognuno di questi può evitare di vedere l'implementazione del codice base chiamata.
Se scrivi codice che accede direttamente a questa implementazione in un modo che non dà a nessuno la possibilità di sostituirlo con altre implementazioni, hai violato l'OCP prima della modifica. Non farlo se non sei assolutamente sicuro che l'implementazione non avrà mai bisogno di cambiare o che sei disposto ad assumerti i costi di apportare modifiche dirette alla implementazione.
Non è che il principio non affronti la necessità di cambiare direttamente l'implementazione della classe base. Ti dice espressamente di evitare di creare una necessità per farlo.
Nel mondo reale a volte cambiare requisiti significa cambiare le cose, ma ci sono modi per mitigare la frequenza con cui ciò accade. SOLID è un elenco di principi che a volte competono tra di loro e spetta allo sviluppatore determinare quali sono i più importanti per la situazione a portata di mano.
Per modificare gli algoritmi, una soluzione comune consiste nell'usare il modello di strategia per richiedere l'algoritmo da fornire quando l'oggetto viene creato in fase di esecuzione e pertanto è possibile utilizzare oggetti diversi. Anche questo fa parte del principio di inversione delle dipendenze. Consente di utilizzare i gradi di calcolo come esempio, ci possono essere più modi di curvare o non gradi di curva, quindi la classe che calcola i gradi richiede una funzione per fornire quella curva come parte della sua creazione. Ciò significa che puoi avere la stessa classe calcolare i voti in modo diverso senza modificare quella classe.
Un altro modo per aiutare a mantenere le classi chiuse è il principio della responsabilità unica, che può anche aiutare a decidere quando una classe deve essere modificata. Se c'è un cambiamento nella responsabilità di una classe è molto probabile che dovrai modificarlo. se una classe ha più responsabilità è molto più probabile che abbia bisogno di essere modificata e avere una maggiore possibilità di causare bug perché si stanno modificando più responsabilità contemporaneamente. Per calcolare i voti puoi avere una classe base che si preoccupa solo del processo di calcolo del punteggio ed estendere con le classi responsabili della formattazione di quel punteggio come lettera, percentuale, pass / fail o qualcos'altro.
Idealmente l'unica ragione per cui una classe dovrebbe essere modificata sono i requisiti direttamente correlati al suo cambiamento di responsabilità. A seconda del dominio questo può essere costante o estremamente raro.
Una classe dovrebbe essere chiusa alla modifica. Tuttavia è aperto all'estensione.
Quindi se la tua classe ha un metodo, AddOne , che ne aggiunge uno a un valore, allora AddOne non dovrebbe essere modificato un giorno per aggiungere due a un valore. Sarebbe una modifica e la classe è chiusa a questo.
Invece, viene aggiunto un nuovo metodo, AddTwo , che gestisce il nuovo algoritmo. Questa è l'estensione e la classe è aperta a questo.
L'eccezione alla regola è se si trova un errore in AddOne . Quindi il suo comportamento può essere modificato.
Leggi altre domande sui tag c# object-oriented-design solid