Er flaggvariabler et absolutt ondskap? [lukket]

Problemet jeg har sett når jeg vedlikeholder kode som bruker flagg, er at antall stater vokser raskt, og det er nesten alltid ubehandlede stater. Ett eksempel fra min egen erfaring: Jeg jobbet med en kode som hadde disse tre flaggene

bool capturing, processing, sending; 

Disse tre opprettet åtte stater (faktisk var det to andre flagg også). Ikke alle mulige verdikombinasjoner ble dekket av koden, og brukerne så feil:

if(capturing && sending){ // we must be processing as well ... } 

Det viste seg at det var situasjoner der antagelsen i if-setningen ovenfor var falsk.

Flagg har en tendens til å bli sammensatt over tid, og de skjuler den faktiske tilstanden til en klasse. Derfor bør de unngås.

Kommentarer

• +1, " bør unngås ". Jeg vil legge til noe om ' men flagg er nødvendig i noen situasjoner ' (noen vil kanskje si ' et nødvendig onde ')
• @TrevorBoydSmith Etter min erfaring er de ikke, du trenger bare litt mer enn den gjennomsnittlige hjernekraften du ville brukt til et flagg
• I eksamenen din burde det ha vært et eneste enum som representerer stat, ikke 3 booleans.
• Du kan komme til et lignende problem som jeg ' står overfor akkurat nå. I tillegg til å dekke alle mulige tilstander, kan to applikasjoner dele det samme flagget (for eksempel å laste opp kundedata). I dette tilfellet vil bare én opplasteren bruke flagget, sette det av og lykke til med å finne problemet i fremtiden.

Her er et eksempel når flagg er nyttige.

Jeg har et stykke kode som genererer passord (ved hjelp av en kryptografisk sikker pseudorandom nummergenerator). Innringeren av metoden velger om eller ikke passordet skal inneholde store bokstaver, små bokstaver, sifre, grunnleggende symboler, utvidede symboler, greske symboler, kyrilliske og unicode.

Med flagg er det enkelt å kalle denne metoden:

var password = this.PasswordGenerator.Generate( CharacterSet.Digits | CharacterSet.LowercaseLetters | CharacterSet.UppercaseLetters);

og det kan til og med forenkles til:

 var password = this.PasswordGenerator.Generate(CharacterSet.LettersAndDigits);  

Uten flagg, hva ville metodesignaturen være?

 public byte[] Generate( bool uppercaseLetters, bool lowercaseLetters, bool digits, bool basicSymbols, bool extendedSymbols, bool greekLetters, bool cyrillicLetters, bool unicode);  

kalt slik:

 // Very readable, isn"t it? // Tell me just by looking at this code what symbols do I want to be included? var password = this.PasswordGenerator.Generate( true, true, true, false, false, false, false, false);  

Som nevnt i kommentarene, vil en annen tilnærming være å bruke en samling:

 var password = this.PasswordGenerator.Generate( new [] { CharacterSet.Digits, CharacterSet.LowercaseLetters, CharacterSet.UppercaseLetters, });  

Dette er mye mer leselig sammenlignet med settet med true og false, men har fremdeles to ulemper:

Den største ulempen er at for å tillate kombinerte verdier, som CharacterSet.LettersAndDigits du skriver noe sånt i Generate() metode:

 if (set.Contains(CharacterSet.LowercaseLetters) || set.Contains(CharacterSet.Letters) || set.Contains(CharacterSet.LettersAndDigits) || set.Contains(CharacterSet.Default) || set.Contains(CharacterSet.All)) { // The password should contain lowercase letters. }  

muligens omskrevet slik:

 var lowercaseGroups = new [] { CharacterSet.LowercaseLetters, CharacterSet.Letters, CharacterSet.LettersAndDigits, CharacterSet.Default, CharacterSet.All, }; if (lowercaseGroups.Any(s => set.Contains(s))) { // The password should contain lowercase letters. }  

Sammenlign dette med det du har ved å bruke flagg:

 if (set & CharacterSet.LowercaseLetters == CharacterSet.LowercaseLetters) { // The password should contain lowercase letters. }  

The s Økologisk, veldig liten ulempe er at det ikke er klart hvordan metoden vil oppføre seg hvis den kalles slik:

 var password = this.PasswordGenerator.Generate( new [] { CharacterSet.Digits, CharacterSet.LettersAndDigits, // So digits are requested two times. });  

Kommentarer

• Jeg tror OP viser til boolske eller heltallvariabler som du tildeler en verdi på bestemte steder, så sjekker du ned under å gjøre noe eller ikke, som for eksempel å bruke newItem = true så noen linjer under if (newItem ) then
• @MainMa Tilsynelatende der ' sa 3.: Versjonen med 8 boolske argumenter er det jeg tenkte på når jeg leste " flagg " …
• Beklager, men IMHO dette er det perfekte tilfellet for metodekjetting ( en.wikipedia.org/wiki/Method_chaining), I tillegg kan du bruke en parametermat (må være en assosiativ matrise eller et kart), der en hvilken som helst oppføring i parametermatrisen du utelater, bruker standardverdiavvik for den parameteren. Til slutt kan samtalen via metodekjetting eller parameterarrayer være like kortfattet og uttrykksfull som bitflagg. Ikke alle språk har bitoperatorer (jeg liker faktisk binære flagg, men vil bruke metodene jeg nettopp nevnte i stedet). / li>
• Det er ', ikke sant? Jeg ' d lager et grensesnitt ala: String myNewPassword = makePassword (randomComposeSupplier (new RandomLowerCaseSupplier (), new RandomUpperCaseSupplier (), new RandomNumberSupplier)); med streng makePassword (leverandør < Tegn > charSupplier); og leverandør < Tegn > randomComposeSupplier (leverandør < Tegn > … leverandører); Nå kan du gjenbruke leverandørene dine til andre oppgaver, komponere dem på den måten du vil, og forenkle genererePassword-metoden din slik at den bruker minimal tilstand.
• @Dibbeke Snakk om en substantivriket …