Qual è il significato e il ragionamento dietro il Principio Aperto / Chiuso?

Il Principio Aperto / Chiuso afferma che le quadro software (classi, moduli, ecc.) Dovrebbero essere aperte per l’estensione, ma chiuse per la modifica. Che cosa significa e perché è un principio importante di una buona progettazione orientata agli oggetti?

Significa che dovresti inserire un nuovo codice in nuove classi / moduli. Il codice esistente dovrebbe essere modificato solo per il bug fixing. Le nuove classi possono riutilizzare il codice esistente tramite l’ereditarietà.

Il principio aperto / chiuso ha lo scopo di mitigare i rischi quando si introducono nuove funzionalità. Dal momento che non si modifica il codice esistente, si può essere certi che non verrà interrotto. Riduce i costi di manutenzione e aumenta la stabilità del prodotto.

È la risposta al fragile problema della class base, che dice che le modifiche apparentemente innocenti alle classi base possono avere conseguenze non volute per gli eredi che dipendevano dal comportamento precedente. Quindi bisogna stare attenti a incapsulare ciò che non si vuole fare in modo che le classi derivate obbediscano ai contratti definiti dalla class base. E una volta che gli eredi esistono, devi essere molto attento a ciò che cambi nella class base.

Più specificamente di DaveK, in genere significa che se si desidera aggiungere funzionalità aggiuntive o modificare le funzionalità di una class, creare una sottoclass invece di modificare l’originale. In questo modo, chiunque usi la class genitore non deve preoccuparsi che cambi in seguito. Fondamentalmente, si tratta di retrocompatibilità.

Un altro principio molto importante della progettazione orientata agli oggetti è l’accoppiamento lento attraverso un’interfaccia di metodo. Se la modifica che si desidera apportare non influisce sull’interfaccia esistente, è davvero sicuro cambiare. Ad esempio, per rendere un algoritmo più efficiente. I principi orientati agli oggetti devono essere mitigati dal buon senso 🙂

Le entity framework software dovrebbero essere aperte per l’estensione ma chiuse per la modifica

Ciò significa che qualsiasi class o modulo dovrebbe essere scritto in modo che possa essere usato così com’è, può essere esteso, ma modificato

Cattivo esempio in Javascript

var juiceTypes = ['Mango','Apple','Lemon']; function juiceMaker(type){ if(juiceTypes.indexOf(type)!=-1) console.log('Here is your juice, Have a nice day'); else console.log('sorry, Error happned'); } exports.makeJuice = juiceMaker; 

Ora se vuoi aggiungere un altro tipo di Juice, devi modificare il modulo stesso, in questo modo stiamo rompendo l’OCP.

Buon esempio in Javascript

 var juiceTypes = []; function juiceMaker(type){ if(juiceTypes.indexOf(type)!=-1) console.log('Here is your juice, Have a nice day'); else console.log('sorry, Error happned'); } function addType(typeName){ if(juiceTypes.indexOf(typeName)==-1) juiceTypes.push(typeName); } function removeType(typeName){ let index = juiceTypes.indexOf(typeName) if(index!==-1) juiceTypes.splice(index,1); } exports.makeJuice = juiceMaker; exports.addType = addType; exports.removeType = removeType; 

Ora puoi aggiungere nuovi tipi di succo dall’esterno del modulo senza modificare lo stesso modulo.

Il principio significa che dovrebbe essere facile aggiungere nuove funzionalità senza dover modificare funzionalità esistenti, stabili e testate, risparmiando tempo e denaro.

Spesso, il polimorfismo, ad esempio l’utilizzo di interfacce, è un buon strumento per raggiungere questo objective.

Un’ulteriore regola empirica per conformarsi a OCP è rendere astratte le classi di base rispetto alla funzionalità fornita dalle classi derivate. O come Scott Meyers dice “Rendi le classi non foglia astratte”.

Ciò significa avere metodi non implementati nella class base e implementare solo questi metodi in classi che non hanno sottoclassi. Quindi il client della class base non può fare affidamento su una particolare implementazione nella class base poiché non ce n’è.

Voglio solo sottolineare che “Aperto / Chiuso”, sebbene sia ovviamente utile nella programmazione OO, è un metodo sano da utilizzare in tutti gli aspetti dello sviluppo. Ad esempio, nella mia esperienza personale è un grande antidolorifico usare il più ansible “Aperto / Chiuso” quando si lavora con la C.

/Roberto

Ciò significa che il software OO dovrebbe essere costruito, ma non modificato intrinsecamente. Ciò è positivo perché garantisce prestazioni affidabili e prevedibili dalle classi base.

Di recente mi è stata data un’idea in più di ciò che questo principio comporta: che il Principio Open-Closed descrive contemporaneamente un modo di scrivere codice, nonché un risultato finale della scrittura di codice in modo resiliente.

Mi piace pensare a Open / Closed diviso in due parti strettamente correlate:

  • Il codice che è Aperto a cambiare può cambiare il suo comportamento per gestire correttamente i suoi input o richiede modifiche minime per fornire nuovi scenari di utilizzo.
  • Il codice che è chiuso per la modifica non richiede molto se nessun intervento umano per gestire nuovi scenari di utilizzo. Il bisogno semplicemente non esiste.

Pertanto, il codice che presenta un comportamento Aperto / Chiuso (o, se preferisci, soddisfa il Principio Aperto / Chiuso) richiede modifiche minime o nulle in risposta a scenari di utilizzo oltre a quelli per cui è stato originariamente costruito.

Per quanto riguarda l’implementazione? Trovo che l’interpretazione comunemente dichiarata, “Aperto / Chiuso fa riferimento al codice che è polimorfico!” per essere al meglio una dichiarazione incompleta. Il polimorfismo nel codice è uno strumento per ottenere questo tipo di comportamento; Ereditarietà, implementazione … in realtà, ogni principio di progettazione orientato agli oggetti è necessario per scrivere codice che sia resiliente nel modo implicito da questo principio.

Nel principio di progettazione, SOLID – la “O” in “SOLID” sta per principio aperto / chiuso.

Il principio Open Closed è un principio di progettazione secondo cui una class, i moduli e le funzioni devono essere aperti per estensione ma chiusi per la modifica.

Questo principio afferma che la progettazione e la scrittura del codice dovrebbero essere fatte in modo tale da aggiungere nuove funzionalità con modifiche minime nel codice esistente (codice testato). Il design dovrebbe essere fatto in modo da consentire l’aggiunta di nuove funzionalità come nuove classi, mantenendo il più ansible il codice esistente invariato.

Vantaggio del principio di Open Closed Design:

  1. L’applicazione sarà più solida perché non stiamo cambiando la class già testata.
  2. Flessibile perché possiamo facilmente soddisfare nuovi requisiti.
  3. Facile da testare e meno sobject a errori.

Il mio post sul blog su questo:

http://javaexplorer03.blogspot.in/2016/12/open-closed-design-principle.html