Perché molti sviluppatori di software violano il principio di apertura / chiusura?

Perché molti sviluppatori di software violano il principio di apertura / chiusura modificando molte cose come rinominare le funzioni che interromperanno l'applicazione dopo l'aggiornamento?

Questa domanda mi viene in mente dopo le versioni veloci e continue nella libreria React .

Ogni breve periodo noto molti cambiamenti nella sintassi, nei nomi dei componenti, ... ecc

Esempio nella prossima versione di React :

Nuovi avvisi di deprecazione

Il cambiamento più grande è che abbiamo estratto React.PropTypes e React.createClass nei loro pacchetti. Entrambi sono ancora accessibili tramite l'oggetto React principale, ma l'utilizzo di uno dei due registrerà un avviso di deprecazione una tantum alla console quando si è in modalità di sviluppo. Ciò consentirà future ottimizzazioni delle dimensioni del codice.

Questi avvisi non influiranno sul comportamento dell'applicazione. Tuttavia, ci rendiamo conto che potrebbero causare qualche frustrazione, in particolare se si utilizza un framework di test che considera console.error come un errore.

• Questi cambiamenti sono considerati una violazione di tale principio?
• Come principiante a qualcosa come React , come posso impararlo con questi rapidi cambiamenti nella libreria (è così frustrante)?

La risposta di IMHO JacquesB, sebbene contenga molta verità, mostra un fondamentale fraintendimento dell'OCP. Per essere onesti, la tua domanda esprime già anche questo malinteso: le funzioni di ridenominazione interrompono la retrocompatibilità , ma non l'OCP. Se sembra necessaria l'interruzione della compatibilità (o il mantenimento di due versioni dello stesso componente per non interrompere la compatibilità), l'OCP era già stato interrotto in precedenza!

Come già menzionato da Jörg W Mittag nei suoi commenti, il principio non dice "non è possibile modificare il comportamento di un componente" - si dice, si dovrebbe provare a progettare i componenti in modo che siano aperti per essere riutilizzati (o estesi) in diversi modi, senza la necessità di modifiche. Questo può essere fatto fornendo i giusti "punti di estensione", o, come menzionato da @AntP, "decomponendo una struttura di classe / funzione al punto in cui ogni punto di estensione naturale è presente di default." L'IMHO che segue l'OCP non ha nulla in comune con "mantenere invariata la vecchia versione per la retrocompatibilità" ! Oppure, citando il commento di @ DerekElkin di seguito:

L'OCP è un consiglio su come scrivere un modulo [...], non sull'implementazione di un processo di gestione delle modifiche che non consente mai ai moduli di cambiare.

I bravi programmatori usano la loro esperienza per progettare componenti tenendo a mente i punti di estensione "giusti" (o - ancora meglio - in modo che non siano necessari punti di estensione artificiali). Tuttavia, per farlo correttamente e senza inutili sovrastorie, è necessario sapere in anticipo come potrebbero apparire i casi d'uso futuri del componente. Anche i programmatori esperti non possono guardare al futuro e conoscere in anticipo tutti i requisiti imminenti. Ed è per questo che a volte è necessario violare la compatibilità con le versioni precedenti, indipendentemente da quanti punti di estensione ha il componente o da quanto segue l'OCP rispetto a determinati tipi di requisiti, ci sarà sempre un requisito che non può essere implementato facilmente senza modificare il componente.

Il principio di apertura / chiusura presenta vantaggi, ma presenta anche alcuni gravi inconvenienti.

In teoria il principio risolve il problema della retrocompatibilità creando codice che è "aperto per estensione ma chiuso per modifica". Se una classe ha alcuni nuovi requisiti, non modificare mai il codice sorgente della classe stessa ma crea invece una sottoclasse che sostituisce solo i membri appropriati necessari per modificare il comportamento. Pertanto, tutto il codice scritto rispetto alla versione originale della classe non è interessato, quindi puoi essere certo che la modifica non ha interrotto il codice esistente.

In realtà si finisce facilmente con il codice gonfio e un pasticcio confuso di classi obsolete. Se non è possibile modificare alcuni comportamenti di un componente tramite l'estensione, è necessario fornire una nuova variante del componente con il comportamento desiderato e mantenere invariata la versione precedente per la compatibilità con le versioni precedenti.

Supponi di scoprire un difetto di progettazione fondamentale in una classe base da cui ereditano molte classi. Supponiamo che l'errore sia dovuto a un campo privato di tipo errato. Non è possibile risolvere questo problema ignorando un membro. Fondamentalmente devi scavalcare l'intera classe, il che significa che finisci per estenderti Objectper fornire una classe base alternativa - e ora devi anche fornire alternative a tutte le sottoclassi, finendo così con una gerarchia di oggetti duplicata, una gerarchia imperfetta, una migliorata . Ma non è possibile rimuovere la gerarchia difettosa (poiché la cancellazione del codice è una modifica), tutti i futuri client saranno esposti ad entrambe le gerarchie.

Ora la risposta teorica a questo problema è "progettala correttamente la prima volta". Se il codice è perfettamente decomposto, senza difetti o errori, e progettato con punti di estensione preparati per tutte le possibili future modifiche ai requisiti, si evita il disordine. Ma in realtà tutti commettono errori e nessuno può prevedere perfettamente il futuro.

Prendi qualcosa come .NET Framework: porta ancora con sé l'insieme delle classi di raccolta che sono state progettate prima dell'introduzione dei farmaci generici più di un decennio fa. Questo è sicuramente un vantaggio per la retrocompatibilità (è possibile aggiornare il framework senza dover riscrivere nulla), ma gonfia anche il framework e offre agli sviluppatori un ampio set di opzioni in cui molti sono semplicemente obsoleti.

Apparentemente gli sviluppatori di React hanno ritenuto che non valesse la pena il costo in termini di complessità e code-bloat seguire rigorosamente il principio aperto / chiuso.

L'alternativa pragmatica all'apertura / chiusura è la deprecazione controllata. Invece di interrompere la retrocompatibilità in una singola versione, i componenti vecchi vengono mantenuti in giro per un ciclo di rilascio, ma i clienti vengono informati tramite avvisi del compilatore che il vecchio approccio verrà rimosso in una versione successiva. Questo dà ai clienti il ​​tempo di modificare il codice. Questo sembra essere l'approccio di React in questo caso.

(La mia interpretazione del principio si basa su The Open-Closed Principle di Robert C. Martin)

Definirei l'ideale principio aperto / chiuso. Come tutti gli ideali, tiene in scarsa considerazione le realtà dello sviluppo del software. Inoltre, come tutti gli ideali, è impossibile realizzarlo nella pratica: uno si sforza semplicemente di avvicinarsi a quell'ideale nel miglior modo possibile.

L'altro lato della storia è noto come le manette d'oro. Le manette dorate sono ciò che ottieni quando ti schiavi troppo del principio aperto / chiuso. Le manette dorate sono ciò che accade quando il tuo prodotto che non rompe mai la compatibilità all'indietro non può crescere perché sono stati commessi troppi errori del passato.

Un famoso esempio di ciò si trova nel gestore della memoria di Windows 95. Come parte del marketing per Windows 95, è stato affermato che tutte le applicazioni Windows 3.1 avrebbero funzionato in Windows 95. Microsoft ha effettivamente acquisito licenze per migliaia di programmi per testarle in Windows 95. Uno dei casi problematici era Sim City. In realtà, Sim City aveva un bug che lo faceva scrivere nella memoria non allocata. In Windows 3.1, senza un "corretto" gestore di memoria, questo era un piccolo passo falso. Tuttavia, in Windows 95, il gestore della memoria lo rileva e provoca un errore di segmentazione. La soluzione? In Windows 95, se il nome dell'applicazione è simcity.exe, il sistema operativo allenterà effettivamente i vincoli del gestore della memoria per impedire l'errore di segmentazione!

Il vero problema alla base di questo ideale sono i concetti ridotti di prodotti e servizi. Nessuno fa davvero l'uno o l'altro. Tutto si allinea da qualche parte nella regione grigia tra i due. Se pensi a un approccio orientato al prodotto, aprire / chiudere suona come un grande ideale. I tuoi prodotti sono affidabili. Tuttavia, quando si tratta di servizi, la storia cambia. È facile dimostrare che con il principio di apertura / chiusura, la quantità di funzionalità che il tuo team deve supportare deve avvicinarsi asintoticamente all'infinito, perché non puoi mai ripulire la vecchia funzionalità. Ciò significa che il tuo team di sviluppo deve supportare sempre più codice ogni anno. Alla fine raggiungi un punto di rottura.

La maggior parte dei software oggi, specialmente open source, segue una versione rilassata comune del principio aperto / chiuso. È molto comune vedere aperti / chiusi seguiti con slancio per le versioni minori, ma abbandonati per le versioni principali. Ad esempio, Python 2.7 contiene molte "cattive scelte" dai giorni Python 2.0 e 2.1, ma Python 3.0 li ha spazzati via tutti. (Inoltre, il passaggio dal codice di base di Windows 95 al codice di base di Windows NT quando pubblicarono Windows 2000 ha battuto tutti i tipi di cose, ma ha fatto dire che non abbiamo mai a che fare con un gestore di memoria controllando il nome dell'applicazione per decidere il comportamento!)

La risposta di Doc Brown è la più accurata e accurata, le altre risposte illustrano incomprensioni del principio chiuso aperto.

Per articolare in modo esplicito l'equivoco, sembra che ci sia la convinzione che l'OCP significa che non si deve fare i cambiamenti all'indietro incompatibili (o anche eventuali modifiche o qualcosa in questo senso.) L'OCP è sulla progettazione di componenti in modo che non ha bisogno di apportare modifiche per estenderne la funzionalità, indipendentemente dal fatto che tali modifiche siano o meno compatibili con le versioni precedenti. Esistono molte altre ragioni oltre all'aggiunta di funzionalità che è possibile apportare modifiche a un componente, indipendentemente dal fatto che siano compatibili all'indietro (ad esempio refactoring o ottimizzazione) o incompatibili all'indietro (ad esempio, deprecando e rimuovendo la funzionalità). Il fatto che tu possa apportare queste modifiche non significa che il tuo componente abbia violato l'OCP (e sicuramente non significa che tu stanno violando l'OCP).

Davvero, non si tratta affatto del codice sorgente. Una dichiarazione più astratta e pertinente dell'OCP è: "un componente dovrebbe consentire l'estensione senza la necessità di violare i suoi confini di astrazione". Vorrei andare oltre e dire che una versione più moderna è: "un componente dovrebbe imporre i suoi confini di astrazione ma consentire l'estensione". Anche nell'articolo sull'OCP di Bob Martin mentre "descrive" "chiuso alla modifica" come "il codice sorgente è inviolato", in seguito inizia a parlare di incapsulamento che non ha nulla a che fare con la modifica del codice sorgente e tutto a che fare con l'astrazione confini.

Quindi, la premessa errata nella domanda è che l'OCP è (inteso come) una linea guida sulle evoluzioni di una base di codice. L'OCP è tipicamente slogan come "un componente dovrebbe essere aperto alle estensioni e chiuso alle modifiche da parte dei consumatori". Fondamentalmente, se un consumatore di un componente desidera aggiungere funzionalità al componente, dovrebbe essere in grado di estendere il vecchio componente in uno nuovo con la funzionalità aggiuntiva, ma non dovrebbe essere in grado di cambiare il vecchio componente.

L'OCP non dice nulla sul creatore di un componente che modifica o rimuove la funzionalità. L'OCP non sta sostenendo per sempre la compatibilità dei bug . Come creatore, tu non stai violando l'OCP cambiando o addirittura rimuovendo un componente. Tu, o meglio i componenti che hai scritto, stai violando l'OCP se l'unico modo in cui i consumatori possono aggiungere funzionalità ai tuoi componenti è mutarlo, ad esempio con il patching delle scimmieo avere accesso al codice sorgente e ricompilare. In molti casi, nessuna di queste sono opzioni per il consumatore, il che significa che se il componente non è "aperto per l'estensione" sono sfortunati. Semplicemente non possono usare il componente per le loro esigenze. L'OCP sostiene di non mettere i consumatori della tua biblioteca in questa posizione, almeno per quanto riguarda una classe identificabile di "estensioni". Anche quando è possibile apportare modifiche al codice sorgente o anche alla copia primaria del codice sorgente, è meglio "fingere" di non poterlo modificare poiché ci sono molte potenziali conseguenze negative nel farlo.

Quindi, per rispondere alle tue domande: No, queste non sono violazioni dell'OCP. Nessuna modifica apportata da un autore può costituire una violazione dell'OCP perché l'OCP non è una dimostrazione di modifiche. Le modifiche, tuttavia, possono creare violazioni dell'OCP e possono essere motivate da guasti dell'OCP nelle versioni precedenti della base di codice. L'OCP è una proprietà di un particolare pezzo di codice, non della storia evolutiva di una base di codice.

Al contrario, la compatibilità con le versioni precedenti è una proprietà di una modifica del codice. Non ha senso dire che un pezzo di codice è o non è retrocompatibile. Ha senso solo parlare della retrocompatibilità di alcuni codici rispetto ad alcuni vecchi codici. Pertanto, non ha mai senso parlare del fatto che il primo taglio di un codice sia retrocompatibile o meno. Il primo taglio di codice può soddisfare o non soddisfare l'OCP, e in generale possiamo determinare se un certo codice soddisfa l'OCP senza fare riferimento a nessuna versione storica del codice.

Per quanto riguarda la tua ultima domanda, è discutibilmente fuori tema per StackExchange in generale perché è principalmente basato sull'opinione pubblica, ma in breve è il benvenuto nella tecnologia e in particolare JavaScript, dove negli ultimi anni il fenomeno che descrivi è stato chiamato stanchezza JavaScript . (Sentiti libero di cercare su Google una varietà di altri articoli, alcuni satirici, parlando di questo da più punti di vista.)