Alla luce del principio aperto / chiuso, la proprietà condivisa del codice è ancora importante?

Penso che tu abbia preso questo concetto un po 'troppo alla lettera. Il principio aperto / chiuso si riferisce all'entità all'interno del progetto del software. Ovviamente, una volta che qualcosa è stato fatto e testato, non vorrete più modificarlo. Non dovresti modificarlo. Dovrebbe essere considerato chiuso. Tuttavia, nel corso dei test unitari, le dipendenze esterne possono variare in base alle quali non si ha alcun controllo. Le strutture dati potrebbero cambiare, potrebbe verificarsi un nuovo caso di test che non è stato preso in considerazione durante la produzione iniziale.

Come @RobertHarvey menziona nei commenti, l'implementazione è sempre aperta per le modifiche. I bug devono essere corretti e non possono essere risolti attraverso l'estensione. Tuttavia, ciò che rimane chiuso è il comportamento previsto della classe. Una volta stabilito il comportamento, questo è ciò che è chiuso. Se un test inizia a fallire, potrebbe essere necessario modificare l'entità per correggere l'introduzione di quel bug (attraverso qualunque vettore sia entrato). Tuttavia, in tutti i casi, il comportamento previsto dell'entità dovrebbe rimanere statico e prevedibile.

Detto questo, la proprietà rimane un requisito, non è vero? Anche se l'aspettativa è che non dovrai mai più toccare quel codice perché è testato e funziona, devi essere preparato per la condizione anormale. Potrebbe non essere una priorità così alta, ma la proprietà condivisa sarà sempre necessaria. Hai ragione nel dire che non è "così importante", ma è ancora necessario aver coperto. Il "proprietario" si prenderà cura la maggior parte del tempo? Ovviamente no. Tuttavia, se le cose iniziano a far esplodere e colpiscono il ventilatore, la mancanza di proprietà condivisa può essere catastrofica.

Il diavolo è nei dettagli. Se leggi il capitolo su OCP in Pattern, pratiche e principi , Martin spiega che la natura "chiusa" di OCP è chiuso a un tipo specifico di modifica. Una volta che hai scoperto la necessità di una modifica, chiudi l'artefatto per modifiche simili a quella.

Ad esempio, diciamo che è necessario implementare il sistema di evasione degli ordini per una società di e-commerce. Al primo passaggio, ti interfaccia direttamente con il fornitore di spedizioni scelto dalla tua azienda. Man mano che l'azienda cresce, è necessario supportare diverse compagnie di navigazione. Dovendo cambiare il componente, decidi di proteggere il tuo componente da future modifiche al modo in cui viene gestita la spedizione.

Ecco come si intende interpretare l'OCP. Non è possibile prevedere ogni modifica necessaria per il codice. Ma ogni volta che lo cambi, chiudi la porta per quella categoria di modifiche.

Il principio aperto / chiuso non ha davvero nulla a che fare con la proprietà del codice.

Nel corso del tempo, gli autori e i contributori di una base di codice vanno e vengono. Gli autori potrebbero essere promossi in gestione e non avere il tempo di assistere con la manutenzione e il supporto del codice. L'autore potrebbe essere colpito da un autobus. O l'autore è semplicemente troppo occupato per lavorare su quel pezzo di software e qualcun altro verrà assegnato a lavorarci sopra. Tutti questi motivi fanno parte del motivo per cui la proprietà condivisa del codice è importante. Aperto / chiuso non significa che altri programmatori non guarderanno nelle classi per vedere cosa stanno facendo, specialmente se tentano di eseguire il debug del comportamento del sistema.

Per quanto riguarda le modifiche, penso che bisogna stare attenti lì. Idealmente non dovresti modificare le parti interne delle classi testate. Tuttavia, i tuoi requisiti esterni possono cambiare, o potrebbero essere stati incompleti al momento della scrittura. Preferirei modificare gli interni delle classi per essere corretti, quindi avere un comportamento scorretto nelle classi che correggo attraverso le estensioni di quella classe. In un mondo ideale , ciò che è nella classe interna è corretto, devi solo fornire più se l'estensione. Ma la realtà a volte gioca diversamente.