Do you think enums need to have a reason to be in order? Like, the example I was looking at today said winter, spring, summer, and autumn. But this is a cyclical order. Is an enum the best representation of a cyclical order? Isn’t it more of a ordinal number thing?
This should be a different post, but it depends on what you’re planning to do with them. Enums are flexible and could totally make do there regardless of semantic cyclical-ness. Remember with enums you’re able to just ignore the values altogether; that’s one of the major reasons to use them. If I have a limited list of flags that I use directly in code, they don’t have to change at runtime, and don’t need additional data associated to them (like ‘number of days’ or something similar), I’ll use an enum.
If you wanted to actually cycle though them in your code, it might be clearer to use both a manager class with a enum. Inside the class, you could use a something like a CurrentSeason property and have a NextSeason, PreviousSeason method to cycle through them. Using modular arithmetic would allow you to change the number of items to cover future features like seasonal transitions or something without having to modify any of your code.
Do you think enums need to have a reason to be in order? Like, the example I was looking at today said winter, spring, summer, and autumn. But this is a cyclical order. Is an enum the best representation of a cyclical order? Isn’t it more of a ordinal number thing?
This should be a different post, but it depends on what you’re planning to do with them. Enums are flexible and could totally make do there regardless of semantic cyclical-ness. Remember with enums you’re able to just ignore the values altogether; that’s one of the major reasons to use them. If I have a limited list of flags that I use directly in code, they don’t have to change at runtime, and don’t need additional data associated to them (like ‘number of days’ or something similar), I’ll use an enum.
If you wanted to actually cycle though them in your code, it might be clearer to use both a manager class with a enum. Inside the class, you could use a something like a CurrentSeason property and have a NextSeason, PreviousSeason method to cycle through them. Using modular arithmetic would allow you to change the number of items to cover future features like seasonal transitions or something without having to modify any of your code.
I was employing subtlety as a strong suit. Wasn’t it obvious?