Il principio aperto/chiuso sembra riguardare la prevenzione delle regressioni in un oggetto o metodo. Dato che il tuo codice è coperto da test perché stai praticando BDD, questo sembra un requisito ridondante. Inoltre, sembra introdurre ulteriore complessità richiedendo l'estensibilità a livello di API piuttosto che a livello di lingua.Ci sono dei vantaggi nel seguire il principio di apertura/chiusura quando si usa BDD?
Assolutamente ci sono vantaggi. In effetti, i due principali (BDD e Open/Closed) sono progettati per scopi diversi. BDD è progettato per guidare il processo di sviluppo, ed è qui che si percepiscono i suoi benefici (riduzione delle tempistiche, realizzazione di codice di qualità superiore, ecc.). Aperto/Chiuso è progettato per essere eseguito nel processo di sviluppo, ma aiuta nella manutenzione.
I vantaggi del BDD sono facili da comprendere. Tempi più brevi per lo sviluppo iniziale significano meno costi per il progetto nel suo insieme, giusto? Sbagliato. Basato su The 60/60 Rule, il 60% del costo del progetto è da mantenerlo (e il 60% di tale costo deriva da modifiche dei requisiti post-distribuzione). Quindi, mentre è vantaggioso risparmiare denaro durante la fase di sviluppo iniziale, i maggiori risparmi devono essere ottenuti durante la manutenzione.
Ed è qui che il principale Open/Closed pagherà. Seguendo questo principio, ci si risparmia un sacco di tempo nella manutenzione (dal momento che non è necessario rintracciare i Test unità rotti perché si modifica la funzionalità di un metodo).
E il principio Open/Closed non riguarda la prevenzione delle regressioni tanto quanto impedisce un'API in modifica che è quasi impossibile tenere il passo con. Se si nota, le buone API non cambiano mai. Possono essere estesi. Le parti potrebbero essere deprecate. Ma non vedi mai setFoo(string bar) passare a setFoo(int bar). Ecco cosa Open/Closed è lì per prevenire ...
Capisco perché non vuoi che la tua API cambi. Dove non sono così sicuro è quando vuoi aggiungere all'api di una classe. Non sono sicuro di aver aperto/chiuso correttamente, ma sembra suggerire che non dovresti cambiare una classe per niente una volta chiusa. Se questo è il caso, sembra che sia in conflitto con altri principi come non ottimizzare la progettazione iniziale e emergente attraverso il refactoring. Forse mi sbaglio e si riferisce solo alla chiusura dei singoli metodi? – opsb
@opsb: Penso che tu abbia eseguito il grokking correttamente. Applicato alle classi, il principio aperto/chiuso dice "sai come puoi aggiungere nuovi metodi a una classe, ed è ancora completamente compatibile con tutti i codici esistenti? Beh, non farlo, ma crea una nuova classe con tutte le funzionalità della vecchia classe, e anche di più. Questa nuova classe può essere una sottoclasse della vecchia classe se aiuta ". Puoi anche provare ad anticipare la necessità di cambiare attraverso l'iniezione delle dipendenze, il modello di strategia e qualsiasi altro trucco che puoi immaginare per rendere le tue lezioni più flessibili senza doverle modificare. –
È la sottoclasse per aggiungere nuove funzionalità che mi mettono a disagio. Dato che la tua API non è cambiata e stai aggiungendo solo funzionalità, non riesco a vedere il vantaggio di frammentare ciò che dovrebbe essere una singola classe attraverso 2 classi, cioè dato che non hai assicurato nessuna regressione nella tua API esistente, quale giustificazione c'è per usare un disegno che in qualsiasi altro punto del processo sarebbe considerato inferiore. – opsb
Ci sono un sacco di tecniche agili che non si applicano alle API che hai pubblicato al di fuori della tua organizzazione, perché è semplicemente impossibile aggiornare tutto il codice che dipende sull'interfaccia che stai cambiando. open/closed è più adatto a quel genere di cose, penso, o in generale alle interfacce (se ce ne sono) che progetti per permanenza. –