|
When I tweeted about this while I was refactoring, someone told me: “Using a boolean is an antipattern”… well… now I experienced it myself. From this experience, in the future, I’ll never use a Boolean field again, and always start with an Enum, especially with a Document database where migrating data is a bit more complex than with relational databases. State management is not ideal for a boolean value, but booleans have value.
|
|
|
|
|
Have to say this is a good point. However there are times where boolean field works great. However, if you are dealing with states, then can always end up with more than 2. I have had cases in the past where that became the case. There is also the advantage of enums in that the name is more descriptive than just yes/no.
|
|
|
|
|
I disagree. The problem he described in the article is not the choice of data type to use, but rather simply a lack of requirements analysis.
If it's not broken, fix it until it is
|
|
|
|
|
Requirements always change ... and change in the one place you didn't allow for!
All round good guy.
|
|
|
|
|
Absolutely… use the right tool for the right job.
|
|
|
|
|
Oh. My. God.
He should better use a string, so he can put anything into it! Or, if he doesn't like refactoring, think abotu the problem first.
|
|
|
|
|
I think a binary field holding a .gif that describes the state of the record would allow for more flexibility. You could encode additional information in the image itself. In fact, for a single record I don't know why all the information couldn't be contained on a single piece of paper.
I think I just talked myself back into the 1950's.
|
|
|
|
|
I have seen the light. I have been wrong, all this time. From now on, all the code I write is going to contain this enumeration:
public enum LogicalStatus
{
True,
False
} Now, all my code will be beautiful. I am assured that I will be able to ascend to a higher level of consciousness now.
|
|
|
|
|
Pete O'Hanlon wrote: Now, all my code will be beautiful.
And I will know who to blame when I see this in some code sometime in the future. "Oh, I read this on the Code Project by a reputable member and have been programming like this ever since. In fact, I've extended the pattern:
public enum Integers
{
One,
Two,
Three,
Four,
}
but for some strange reason, I have to keep adding new Integers! Plz Help. Urgentz!"
Marc
|
|
|
|
|
You fool. You've prematurely optimized. Don't you know that you should be using the Visitor pattern here, possibly combined with DI to inject new numbers as and when you see fit? Of course, I expect to see a full implementation for Doubles and Floats while you are at it (and just to be on the safe side, I think you need to represent all possible combinations of strings).
|
|
|
|
|
And add a snuff of IoC, so you can switch it out at runtime with some 3rd party library providing the implementation!
Wout
|
|
|
|
|
FTFY:
[Flags]
public enum LogicalStatus : byte {
False = 0,
True = 1
}
Wout
|
|
|
|
|
Hey Pete, I was wanting to poke around CodeStash, but I'm getting: "Google Chrome could not connect to www.codestash.co.uk"
Is the site still up?
Marc
|
|
|
|
|
Hi Marc,
I've just had to ask the CodeProject team to restart the server as it's hosted on their servers.
Regards
Pete
|
|
|
|
|
Pete O'Hanlon wrote: I've just had to ask the CodeProject team to restart the server as it's hosted on their servers.
Hmmm, it's still not responding. I guess the hamsters are on vacation.
Marc
|
|
|
|
|
It's back Marc. Turns out that the server had been switched between Amazon instances and the DS settings hadn't been updated to point to the new instance. I'm putting monitoring in place to warn me if this happens again in the future.
|
|
|
|
|
Pete O'Hanlon wrote:
Thanks! One of the reasons I wanted to poke around the site was because I have another hair-brained idea that applications should consist of small, either re-usable or custom code blocks that are wired together with a tool like Visio. Ultimately I envision something that is a mix between what that website, code bubbles, does, and something like lego-building blocks where you can visually wire up the data flow and events. The actual granularity would be completely flexible, and I imagine larger scale building blocks for handling things like ORM's, etc.
I'm still looking for a decent visualization tool, similar to Visio. Sacha's rework of the WPF layout tool looks like a very good starting point.
So I wanted to see what people had contributed for snippets to 1) see if you were already doing some of this with CodeStash and 2) to see what people were contributing.
Argh. I need time!!!
Marc
|
|
|
|
|
If you need a hand, just let me know as this sounds fascinating. I'm currently planning quite a reimplementation of CodeStash based on feedback we've had, and the lessons we learnt building V1, so if there's anything that you need out of it, please let me know.
|
|
|
|
|
Pete O'Hanlon wrote: If you need a hand, just let me know as this sounds fascinating.
I would really enjoy your participation! Can you send a private email so I can get your email address? What I'd like to do is storyboard a simple demonstration of the concept - I believe in writing the minimum amount of code necessary to get a conceptual prototype working! I'll send you the storyboard and I would like to discuss it with you.
Marc
|
|
|
|
|
Hopefully my email got through.
|
|
|
|
|
Pete O'Hanlon wrote: Hopefully my email got through.
Yes it did! I've been running around town today, but I just started putting together the concept as, what else, a Power Point slide deck! Mwahahaha!
I'll email it to you as soon as I get a rough draft done.
Marc
|
|
|
|
|
Excellent. I look forward to seeing it.
|
|
|
|
|
Yea.. no. Preemptively using an enum is a good example of YAGNI.
|
|
|
|
|
Terrence Dorsey wrote: Using a boolean is an antipattern
It's only an anti-pattern if you cocked up the design stage and didn't think it through properly.
Terrence Dorsey wrote: From this experience, in the future, I’ll never use a Boolean field again, and always start with an Enum
Seriously? You committed that statement to a blog post that will haunt you for the rest of your career?
Using a boolean is not an anti-pattern unless it was the wrong choice in the first place.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
The problem here is with this:
I needed to keep track of whether someone has paid or not, so I started modeling that field as a simple boolean value, HasPaid.
He should have realized from the get-go, by simply thinking of use-cases in his head, that a boolean would not be appropriate. But so often, I find that people don't think of use-cases as their coding, and then they blame someone / something else for the eventual problem that they get into. And hence we have refactoring, which is another word for "Doh!"
The problem isn't with booleans, it's with the programmer!
Marc
|
|
|
|