标志枚举和放大器;位运算与“位串” [英] Flags enum & bitwise operations vs. “string of bits”

查看:130
本文介绍了标志枚举和放大器;位运算与“位串”的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

一个家伙开发商建议我们存储选择一周的日子为星期一和星期五1和0的,即1000100的7个字符的字符串。我preferred(并强烈建议)具有标志枚举和位运算的解决方案,我认为这是这样做的更清洁的方式,它应该为其他开发人员更易于理解。

A fellow developer suggested we store a selection of days of the week as 7-character string of 1’s and 0’s, i.e. "1000100" for Monday and Friday. I preferred (and strongly suggested) a solution with a Flags enum and bitwise operations, I think it's a cleaner way of doing this, and it should be easier to understand for other developers.

  [Flags()]
  public enum Weekdays : int
  {
    Monday = 1,
    Tuesday = 2,
    Wednesday = 4,
    Thursday = 8,
    Friday = 16,
    Saturday = 32,
    Sunday = 64
  }

不过,正如我开始实施样品溶液,我意识到,也许毕竟是简单的字符串的方法是比较容易:当然,位字符串比17更明显,如果你只是看数据。而且我发现C#位运算的反直观,非常详细:

However, as I started to implement a sample solution, I realized that maybe the simple string approach was easier after all: Certainly the bit-string is more obvious than "17" if you’re just looking at the data. And I find the C# bitwise operations counter-intuitive and extremely verbose:

Weekdays workDays = Weekdays.Monday | Weekdays.Tuesday;
if ((workDays & Weekdays.Monday) == Weekdays.Monday) 
{...}

当然,这可以很好地裹进扩展方法,但后来我们突然至少相同数量code线与字符串的解决方案的结束,我几乎不能认为按位code是更容易阅读。

Of course this could be wrapped nicely into extension methods, but then we suddenly end up with at least the same number of lines of code as with the string-solution, and I can hardly argue the bitwise code is easier to read.

话虽这么说,我还是会去的一个标志枚举和位运算。我能想到的主要优点是

That being said, I still would go with a flags enum and bitwise operations. The key benefits I can think of are


  • 更好的性能

  • 需要的存储空间更少

那么,如何卖出位运算解决我的同事吗?我是不是该?什么是使用过的字符串这种方法的其他好处?完成样品项目后,我发现球队依然选择了基于字符串的解决方案。我需要一些更好/更强大的参数。
为什么要使用标志枚举,而不是简单的比特串?

So how do I sell the bitwise solution to my colleagues? Should I? What are the other benefits of using this method over strings? After completing the sample project, I found that the team still opted for the string-based solution. I need some better/stronger arguments. Why should you use Flags enums rather than simple bit-strings?

推荐答案

使用标志枚举的优点:

使用标志枚举的否定:


  • 数据重新$ P $人类很难psentation理解(17设为例如什么标志?)



使用的比特串的好处:


  • 易于为程序员,看看哪些比特字符串设置

使用的比特串的否定:


  • 非标准方法

  • 更难理解与您的设计
  • 不熟悉的程序员
  • 潜在容易设置的垃圾的价值观(例如stringValue的=星期天)

  • 不用字符串创建

  • 不用字符串解析

  • 其他开发工作

  • 重新发明轮子(而不是连一个圆轮)

  • Non-standard approach
  • Harder to understand for programmers unfamiliar with your design
  • Potentially easier to set "garbage" values (e.g. stringValue = "Sunday")
  • Needless string creation
  • Needless string parsing
  • Additional development work
  • Reinventing the wheel (but not even a round wheel)



如何重要的是它真的能看比特串,看看有什么设置?如果你很难知道17是周一和周五,你总是可以使用计算器和转换为二进制。或者添加某种字符串重新presentation为显示(或调试)使用。这不是的的困难。


它还在我看来,如果你打算让比特串接近固体,那么你将需要做相当多的封装,以使其达到一个抽象层,该标志枚举已经提供。如果方法是简单地处理比特串直接那么这将是难以阅读(和理解),可能容易出错。


It also seems to me that if you are going to make the string of bits approach solid then you will need to do quite a bit of encapsulation to bring it up to a level of abstraction that the Flags enum already provides. If the approach is to simply manipulate the string of bits directly then that is going to be hard to read (and understand) and probably error prone.

例如。你可能会看到这样的:

e.g. you may end up seeing this:

days = "1000101"; // fixed bug where days were incorrectly set to "1010001"

这篇关于标志枚举和放大器;位运算与“位串”的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆