Illustrerò il problema con un caso specifico. Supponiamo di avere un tipo di enumerazione di stile bit-flag che definisce diversi tipi di convalida. Si è tentati di definire un enumeratore come FULL_VALIDATION con tutti i bit impostati. La giustificazione più ovvia (e superficiale) è la convenienza. Gli utenti non hanno più bisogno esplicitamente di bit o forse di un numero elevato di enumeratori specifici.
Mentre un enumeratore di questo tipo può sembrare a prima vista normale, alcune preoccupazioni mi vengono in mente dopo un secondo pensiero. Man mano che la libreria evolve, è possibile aggiungere nuovi tipi di convalida, che non esistono nelle versioni precedenti. Di conseguenza, FULL_VALIDATION implicherà una convalida più severa rispetto a prima. Il codice utente che viene eseguito correttamente nelle versioni precedenti potrebbe non riuscire con quello nuovo. In un certo senso, questo può essere classificato come un cambio di rottura (pensavo che non lo vedessi in questo modo).
Quindi, la domanda è: un enumeratore così onnicomprensivo è appropriato? Personalmente, sono favorevole alla sua definizione. La semantica esatta di FULL_VALIDATION dovrebbe essere: fai il maggior numero possibile di convalide . Incorporando nuove convalide in questo enumeratore, non stiamo rompere questa semantica (o contratto, promessa, interfaccia, quale preferite). Non è necessario modificare la documentazione relativa a questo enumeratore. A questo proposito, le sottigliezze con questo enumeratore sono più di una caratteristica di una bomba.
La semantica dell'enumeratore è intrinsecamente imprecisa e inesatta. Questo è proprio quello che dovrebbe essere, e dovrebbe essere quello che gli utenti si aspettano e vogliono se scelgono di usarlo. Nonostante sia un po 'ambiguo, questo è in realtà un design abbastanza flessibile. Usando un tale enumeratore, consenti al tuo codice di evolvere con la libreria, approfittando di tutte le nuove funzionalità man mano che appaiono. Al contrario, se esplicitamente OR bit a bit un numero di specifici enumeratori, sei bloccato e non ottieni la flessibilità e l'evolvibilità.
Riguardo alle "interruzioni di modifiche" che possono derivare dall'uso di un tale enumeratore, penso che non sia solo OK, ma che dovrebbe essere effettivamente rallegrato. Un bug che non riesce a manifestarsi è ancora un bug. Quello che sta realmente accadendo qui è che con la nuova versione della libreria e le sue convalide più potenti, siamo riusciti a rivelare un altro bug nel codice utente. Quindi, non è un problema della libreria, ma del codice utente. Gli utenti dovrebbero essere soddisfatti di questo. È uno dei vantaggi e dei vantaggi dell'uso dell'enumeratore FULL_VALIDATION . Ultimo ma non meno importante, gli utenti dovrebbero SEMPRE eseguire test di regressione quando si spostano su nuove versioni di librerie dipendenti.
Quanto sopra è quello che ho pensato. Per essere sicuro e prendere decisioni informate, voglio anche le idee da voi ragazzi.