Refactoring e principio aperto / chiuso

Recentemente sto leggendo un sito web sullo sviluppo di codice pulito (non inserisco un link qui perché non è in inglese).

Uno dei principi pubblicizzati da questo sito è il principio chiuso aperto : ogni componente software deve essere aperto per l'estensione e chiuso per modifica. Ad esempio, quando abbiamo implementato e testato una classe, dovremmo modificarla solo per correggere bug o aggiungere nuove funzionalità (ad esempio nuovi metodi che non influenzano quelli esistenti). Le funzionalità e l'implementazione esistenti non devono essere modificate.

Normalmente applico questo principio definendo un'interfaccia Ie una corrispondente classe di implementazione A. Quando la classe Aè diventata stabile (implementata e testata), di solito non la modifico troppo (forse, per niente), cioè

1. Se arrivano nuovi requisiti (ad es. Prestazioni o un'implementazione totalmente nuova dell'interfaccia) che richiedono grandi modifiche al codice, scrivo una nuova implementazione Be continuo a utilizzarla Afinché Bnon è matura. Quando Bè maturo, tutto ciò che serve è cambiare la modalità di Iistanza.
2. Se i nuovi requisiti suggeriscono anche una modifica all'interfaccia, definisco una nuova interfaccia I'e una nuova implementazione A'. Così I, Asono congelati e restano l'attuazione del sistema di produzione più a lungo I'e A'non sono abbastanza stabili per sostituirli.

Quindi, alla luce di queste osservazioni, sono rimasto un po 'sorpreso dal fatto che la pagina web abbia poi suggerito l'uso di refactoring complessi , "... perché non è possibile scrivere il codice direttamente nella sua forma finale".

Non esiste una contraddizione / conflitto tra l'applicazione del principio aperto / chiuso e la proposta di utilizzare refactoring complessi come best practice? O l'idea qui è che si possono usare refactoring complessi durante lo sviluppo di una classe A, ma quando quella classe è stata testata con successo dovrebbe essere congelata?

Penso al principio Open-Closed come obiettivo progettuale . Se finisci per doverlo violare, significa che il tuo progetto iniziale è fallito, il che è certamente possibile e persino probabile.

Il refactoring significa che stai cambiando il design senza cambiare la funzionalità. Probabilmente stai cambiando il tuo design perché c'è un problema con esso. Forse il problema è che è difficile seguire il principio aperto-chiuso quando si apportano modifiche al codice esistente e si sta tentando di risolverlo.

È possibile che si stia eseguendo un refactoring per rendere possibile l'implementazione della funzionalità successiva senza violare l'OCP quando lo si esegue.

Il principio Open-Closed è più un indicatore di quanto bene è progettato il tuo software ; non un principio da seguire letteralmente. È anche un principio che ci aiuta a impedirci di cambiare accidentalmente le interfacce esistenti (classi e metodi che chiami e come ti aspetti che funzionino).

L'obiettivo è scrivere software di qualità. Una di queste qualità è l'estensibilità. Ciò significa che è facile aggiungere, rimuovere, modificare il codice con quelle modifiche che tendono ad essere limitate al numero di classi esistenti più pratico. L'aggiunta di nuovo codice è meno rischiosa rispetto alla modifica del codice esistente, quindi a questo proposito Open-Closed è una buona cosa da fare. Ma di quale codice stiamo parlando esattamente? Il crimine di violazione di OC è molto meno quando è possibile aggiungere nuovi metodi a una classe invece di dover modificare quelli esistenti.

OC è frattale . Mele a tutte le profondità del tuo design. Tutti presumono che sia applicato solo a livello di classe. Ma è ugualmente applicabile a livello di metodo o a livello di assieme.

Una violazione troppo frequente di OC al livello appropriato suggerisce che forse è il momento di refactoring . "Livello appropriato" è un giudizio che ha tutto a che fare con il tuo progetto complessivo.

Seguire Open-Closed significa letteralmente che il numero di classi esploderà. Creerai inutilmente ("I" maiuscole). Ti ritroverai con un po 'di funzionalità distribuite tra le classi e dovrai quindi scrivere molto più codice per collegarlo tutto insieme. Ad un certo punto ti renderai conto che cambiare la classe originale sarebbe stato meglio.

Il principio Open-Closed sembra essere un principio apparso prima che il TDD fosse più prevalente. L'idea è che è pericoloso refactoring del codice perché potresti rompere qualcosa, quindi è più sicuro lasciare il codice esistente così com'è e semplicemente aggiungerlo ad esso. In assenza di test questo ha senso. L'aspetto negativo di questo approccio è l'atrofia del codice. Ogni volta che estendi una classe invece di refactoring, finisci con un livello aggiuntivo. Stai semplicemente fissando il codice in alto. Ogni volta che aggiungi più codice, aumenti le possibilità di duplicazione. Immaginare; c'è un servizio nella mia base di codice che voglio usare, trovo che non abbia quello che voglio, quindi creo una nuova classe per estenderla e includere la mia nuova funzionalità. Un altro sviluppatore arriva più tardi e vuole anche usare lo stesso servizio. Sfortunatamente, non mi rendo conto che esiste la mia versione estesa. Codificano rispetto all'implementazione originale ma hanno anche bisogno di una delle funzionalità che ho codificato. Invece di usare la mia versione, ora estendono anche l'implementazione e aggiungono la nuova funzionalità. Ora abbiamo 3 classi, quella originale e due nuove versioni che hanno alcune funzionalità duplicate. Seguire il principio aperto / chiuso e questa duplicazione continuerà ad accumularsi per tutta la durata del progetto, portando a una base di codice inutilmente complessa.

Con un sistema ben collaudato non è necessario soffrire di questa atrofia del codice, è possibile eseguire il refactoring sicuro del codice consentendo al progetto di assimilare nuovi requisiti anziché dover fissare continuamente nuovo codice. Questo stile di sviluppo è chiamato design emergente e porta a basi di codice che sono in grado di mantenersi in buona forma per tutta la loro vita piuttosto che raccogliere gradualmente l'innesto.

Nelle parole di laici:

A. Principio O / C significa che la specializzazione deve essere fatta estendendo, non modificando una classe per soddisfare esigenze specializzate.

B. L'aggiunta di funzionalità mancanti (non specializzate) significa che il progetto non è stato completato e devi aggiungerlo alla classe base, ovviamente senza violare il contratto. Penso che questo non stia violando il principio.

C. Il refactoring non viola il principio.

Quando un disegno matura , diciamo, dopo un po 'di tempo in produzione:

• Dovrebbero esserci pochissime ragioni per farlo (punto B), tendendo a zero nel tempo.
• (Punto C) sarà sempre possibile sebbene più raro.
• Tutte le nuove funzionalità dovrebbero essere una specializzazione, il che significa che le classi devono essere estese (ereditate da) (punto A).

Per me, il principio aperto-chiuso è una linea guida, non una regola dura e veloce.

Per quanto riguarda la parte aperta del principio, le classi finali in Java e le classi in C ++ con tutti i costruttori dichiarate private violano la parte aperta del principio aperto-chiuso. Esistono buoni casi d'uso solidi (nota: solido, non SOLIDO) per le classi finali. Progettare per l'estensibilità è importante. Tuttavia, ci vuole molta lungimiranza e impegno, e stai sempre evitando la linea di violazione di YAGNI (non ne avrai bisogno) e iniettando l'odore di codice di generalità speculativa. I componenti software chiave dovrebbero essere aperti per l'estensione? Sì. Tutti? No. Questa in sé è generalità speculativa.

Per quanto riguarda la parte chiusa, quando si va dalla versione 2.0 alla 2.1 alla 2.2 alla 2.3 di alcuni prodotti, non modificare il comportamento è una buona idea. Agli utenti non piace davvero quando ogni versione minore rompe il proprio codice. Tuttavia, lungo la strada si scopre spesso che l'implementazione iniziale nella versione 2.0 era sostanzialmente rotta o che i vincoli esterni che limitavano la progettazione iniziale non erano più applicabili. Sorridi, sopporti e mantieni tale progetto nella versione 3.0, o rendi la 3.0 non compatibile con le versioni precedenti? La compatibilità con le versioni precedenti può essere un enorme limite. I principali limiti di rilascio sono il luogo in cui è accettabile interrompere la compatibilità con le versioni precedenti. Devi stare attento che questo potrebbe far arrabbiare i tuoi utenti. Ci deve essere un buon caso per cui è necessaria questa rottura con il passato.

Il refactoring, per definizione, sta cambiando la struttura del codice senza cambiare comportamento. Pertanto, quando si esegue il refactoring, non si aggiungono nuove funzionalità.

Quello che hai fatto come esempio per il principio Open Close sembra OK. Questo principio riguarda l'estensione del codice esistente con nuove funzionalità.

Tuttavia, non sbagliare questa risposta. Non sottintendo che dovresti fare solo funzionalità o eseguire il refactoring solo per grossi blocchi di dati. Il modo più comune di programmare è fare un po 'di una funzionalità piuttosto che fare immediatamente un po' di refactoring (combinato con i test ovviamente per assicurarsi di non aver modificato alcun comportamento). Il refactoring complesso non significa refactoring "grande", significa applicare tecniche di refactoring complicate e ben ponderate.

Informazioni sui principi SOLID. Sono davvero buone linee guida per lo sviluppo del software ma non sono regole religiose da seguire alla cieca. A volte, molte volte, dopo aver aggiunto una seconda, terza e nona funzionalità, ti rendi conto che il tuo progetto iniziale, anche se rispetta Open-Close, non rispetta altri principi o requisiti software. Ci sono punti nell'evoluzione di un design e di un software quando devono essere fatti cambiamenti più complessi. Il punto è trovare e realizzare questi problemi il prima possibile e applicare le tecniche di refactoring nel miglior modo possibile.

Non esiste un design perfetto. Non esiste un progetto del genere che possa e debba rispettare tutti i principi o i modelli esistenti. Questo è codificare l'utopia.

Spero che questa risposta ti abbia aiutato nel tuo dilemma. Sentiti libero di chiedere chiarimenti se necessario.

Secondo la mia comprensione - se aggiungi nuovi metodi alla classe esistente, allora non si romperà l'OCP. tuttavia sono un po 'confuso con l'aggiunta di nuove variabili nella classe. Ma se si modificano il metodo esistente e i parametri nel metodo esistente, questo sicuramente interromperà l'OCP, perché il codice è già testato e passato se cambiamo intenzionalmente il metodo [Quando cambiano i requisiti], allora sarà un problema.