Come ho spiegato, il principio open / closed afferma che una volta che il codice scritto non deve essere modificato (a parte le correzioni di bug). Ma se le mie regole aziendali cambiano, non dovrei modificare il codice implementando tali modifiche? Sospetto che non capisco qualcosa su come il principio, perché non ha senso per me.
Questo è probabilmente il più duro dei solidi principi da spiegare. Fammi provare. Immagina di aver scritto una classe Invoice che funziona perfettamente e non ha bug. Crea un PDF di una fattura.
Quindi qualcuno dice di volere una fattura HTML con i collegamenti al suo interno. Non si modifica alcun codice in Fattura per soddisfare questa richiesta. Invece, fai un'altra classe, HTMLInvoice, che fa quello che vogliono ora. Sfrutta l'ereditarietà in modo da non dover scrivere molto codice duplicato in HTMLInvoice.
Il vecchio codice che utilizzava la vecchia fattura non è rotto o è realmente interessato in alcun modo. Il nuovo codice può utilizzare HTMLInvoice. (Se si fa anche sostituibilità di Liskov , la L di solido, è possibile fornire istanze HTMLInvoice al codice esistente che è in attesa di fattura istanze). Tutti vivono felici e contenti.
La fattura è chiusa alla modifica, aperta all'estensione. E devi scrivere correttamente la fattura in anticipo perché funzioni, btw.
Hai letto l'articolo The Open-Closed Principle degli amici dello zio Bob su ObjectMentor? Penso che sia una delle migliori spiegazioni là fuori.
There are many heuristics associated with object oriented design. For example, “all member variables should be private”, or “global variables should be avoided”, or “using run time type identification (RTTI) is dangerous”. What is the source of these heuristics? What makes them true? Are they always true? This column investigates the design principle that underlies these heuristics -- the open-closed principle.
As Ivar Jacobson said: “All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version.” How can we create designs that are stable in the face of change and that will last longer than the first version? Bertrand Meyer gave us guidance as long ago as 1988 when he coined the now famous open-closed principle. To paraphrase him:
SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.
Quando una singola modifica a un programma determina una cascata di modifiche ai moduli dipendenti, quel programma mostra gli attributi indesiderati che siamo venuti ad associare al design "cattivo". Il programma diventa fragile, rigido, imprevedibile e insostenibile. Il principio open-closed attacca questo in modo molto semplice. Dice che dovresti progettare moduli che non cambiano mai . Quando i requisiti cambiano, estendi il comportamento di tali moduli aggiungendo un nuovo codice, non modificando il vecchio codice che già funziona.
Descrizione
I moduli conformi al principio open-closed hanno due attributi principali.
- Sono "Open For Extension".
Ciò significa che il comportamento del modulo può essere esteso. Che possiamo fare in modo che il modulo si comporti in modi nuovi e diversi man mano che cambiano i requisiti dell'applicazione o per soddisfare le esigenze delle nuove applicazioni.- Sono "Chiusi per modifica".
Il codice sorgente di tale modulo è inviolato. A nessuno è permesso apportare modifiche al codice sorgente.Sembrerebbe che questi due attributi siano in disaccordo l'uno con l'altro. Il modo normale per estendere il comportamento di un modulo è quello di apportare modifiche a quel modulo. Un modulo che non può essere cambiato normalmente si pensa che abbia un comportamento fisso. Come possono questi due oppositori attributi da risolvere?
L'astrazione è la chiave ...
La risposta di Kate Gregory è molto buona, ma considera una situazione diversa in cui è possibile soddisfare un nuovo requisito con una variazione relativamente piccola nella classe Invoice esistente. Ad esempio, diciamo che un nuovo campo deve essere aggiunto al PDF fattura. Secondo OCP, dovremmo comunque creare una nuova sottoclasse, anche se il nuovo campo potrebbe essere aggiunto all'implementazione esistente cambiando alcune righe di codice.
A mio parere, OCP riflette la realtà degli anni '80 e dei primi anni '90, dove i progetti spesso non utilizzavano nemmeno il controllo della versione, tanto meno i test di regressione automatizzati o il vantaggio di sofisticati strumenti di refactoring. OCP era un tentativo di evitare il rischio di rompere il codice che era stato testato manualmente e messo in produzione. Oggi, abbiamo modi migliori per gestire il rischio di rompere il software di lavoro (vale a dire, i sistemi di controllo delle versioni, TDD e test automatici e strumenti di refactoring).
Personalmente penso che questo principio dovrebbe essere preso con un pizzico di sale. Il codice è organico, le aziende cambiano e il codice cambia in base alle esigenze di un'azienda nel corso del tempo.
Trovo molto difficile capire che l'astrazione è la chiave. E se l'astrazione fosse originariamente sbagliata? Cosa succede se la funzione aziendale è cambiata in modo significativo?
Questo principio garantisce essenzialmente che le intenzioni e il comportamento ORIGINALI di un progetto non debbano mai cambiare. Questo probabilmente funziona per coloro che hanno API pubbliche e i loro clienti hanno problemi a tenere il passo con le nuove versioni e altri casi limite. Tuttavia, se una società possiede TUTTO il codice, allora sfido questo principio.
Avere una buona copertura di test del codice dovrebbe rendere il refactoring del codice base un gioco da ragazzi. Significa che è giusto sbagliare: i tuoi test ti aiuteranno a migliorare il design.
Dicendo che, se non ci sono test, allora questo principio è valido.
Leggi altre domande sui tag object-oriented