Er flagvariabler et absolut ondskab? [lukket]

Det problem, jeg har set, når jeg vedligeholder kode, der bruger flag, er, at antallet af stater vokser hurtigt, og at der næsten altid er uhåndterede stater. Et eksempel fra min egen erfaring: Jeg arbejdede på en kode, der havde disse tre flag

bool capturing, processing, sending; 

Disse tre skabte otte stater (faktisk var der to andre flag såvel). Ikke alle mulige værdikombinationer var dækket af koden, og brugerne så fejl:

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

Det viste sig, at der var situationer, hvor antagelsen i if-sætningen ovenstående var falsk.

Flag har tendens til at blive sammensat over tid, og de skjuler klassens aktuelle tilstand. Derfor bør de undgås.

Kommentarer

• +1, " bør undgås ". Jeg vil tilføje noget om ' men flag er nødvendige i nogle situationer ' (nogle siger måske ' et nødvendigt onde ')
• @TrevorBoydSmith Efter min erfaring er de ikke, du behøver bare lidt mere end den gennemsnitlige hjernekraft, du ville bruge til et flag
• I din eksamens burde det have været et enkelt enum, der repræsenterer tilstand, ikke 3 booleanske.
• Du kommer muligvis til et lignende problem, som jeg ' m vender lige nu. Ud over at dække alle mulige stater kan to applikationer muligvis dele det samme flag (f.eks. Uploade kundedata). I dette tilfælde vil kun en uploader bruge flag, sætte det af og held og lykke med at finde problemet i fremtiden.

Her er et eksempel, når flag er nyttige.

Jeg har et stykke kode, der genererer adgangskoder (ved hjælp af en kryptografisk sikker pseudorandom-talgenerator). Opkalderen til metoden vælger, om eller ikke adgangskoden skal indeholde store bogstaver, små bogstaver, cifre, grundlæggende symboler, udvidede symboler, græske symboler, kyrilliske og unicode.

Med flag er det let at kalde denne metode:

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

og det kan endda forenkles til:

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

Uden flag, hvad ville metodesignaturen være?

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

kaldes sådan:

 // 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 bemærket i kommentarerne ville en anden tilgang være at bruge en samling:

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

Dette er meget mere læsbart sammenlignet med sættet med true og false, men har stadig to ulemper:

Den største ulempe er, at for at tillade kombinerede værdier, som CharacterSet.LettersAndDigits du skriver noget lignende 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. }  

muligvis omskrevet sådan:

 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 hvad du har ved hjælp af flag:

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

s Økonomisk meget lille ulempe er, at det ikke er klart, hvordan metoden opfører sig, hvis den kaldes sådan:

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

Kommentarer

• Jeg mener, OP henviser til boolske eller heltal variabler, som du tildeler en værdi på bestemte steder, så nedenunder kontrollerer du derefter i orther at gøre noget eller ej, som for eksempel at bruge newItem = true så nogle linjer under if (newItem ) then
• @MainMa Tilsyneladende der ' sa 3.: Versionen med 8 boolske argumenter er, hvad jeg tænkte på, da jeg læste " flag " …
• Undskyld, men IMHO dette er det perfekte tilfælde til metodekædning ( da.wikipedia.org/wiki/Method_chaining), Derudover kan du bruge et parameterarray (skal være et associerende array eller kort), hvor enhver post i det parameterarray, du udelader, bruger standardværdioppførelsen for denne parameter. I sidste ende kan opkaldet via metodekædning eller parameterarrays være lige så kortfattede og udtryksfulde som bitflag, og ikke alle sprog har bitoperatorer (jeg kan faktisk godt lide binære flag, men bruger de metoder, jeg lige har nævnt i stedet for). / li>
• Det ' er ikke særlig OOP, er det? Jeg ' d laver en grænseflade 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); Nu kan du genbruge dine leverandører til andre opgaver, komponere dem på enhver måde, du vil, og forenkle din genererePassword-metode, så den bruger minimal tilstand.
• @Dibbeke Tal om en navneordsriget …