位运算的应用之逻辑控制.docx

立工匠精神 铸软件人才位运算的应用之逻辑控制（主观条件类问题）这是一个神器的集合！1,2,4,8,16,32,64,128,256,512,1024对这个神奇的集合就是2的N次幂集合，他们的神奇之处不仅仅在于他们的2进制形式总是1后面N个零，还在于他们的这种2进制形式可以帮助我们方便的解决一些问题，这类问题我们称为主观条件类问题，其本质是如何利用一个整数的每个位作为程序中的独立的标识信息。怎么定义主观条件类问题呢？需要比较现实的案例可以说明。那么问题来了，中国IT哪家最豪气？中关村融科中软国际。于是某A君荣幸的加入中软国际，通过2年的打拼，成为某部门部门经理，结合中软国际不差钱的土豪气质，为下属们设立了每年欧洲10国游的年终福利。当然为了彰显领导权利以便于让所有下属能够以自己为中心围绕在新一代的团队领导班子周围，A君为年终福利设立了入围条件，A君第一年设立的条件如下：1 必须是女性2 年龄小于25岁3 体重小于100公斤凡是符合上述条件的员工都可以跟随A君前往欧洲享受为期1个月的超长旅游休假。在信息技术改变生产力的现代，作为IT企业龙头的中软国际自然也要将公司的所有人、财、事、物均纳入ERP的管控范围，上述业务逻辑自然也不能例外。按照绝大部分初学者的想法，这是一个非常简单的问题，可以在关系型数据库中设计一个表来描述业务逻辑所需要的数据，如下：员工是否女性是否小于25岁是否轻于100KGE1是是是E2是否是E3否是是如此便可以利用数据库表中的数据在程序中获取哪些员工可以跟随A君前往欧洲了，貌似已经完美解决我们提出的问题。然而让人想不到是A君在第二年却要求能再添加一个主观条件：能去欧洲的员工还必须是未婚的。于是ERP感到了亚历山大。为什么呢，因为目前大部分基于关系型数据库的应用系统而言，数据库表结构决定了上层程序的访问方式，原始的数据库表中只有3个条件，我们虽然可以利用SQL语句非常简单方便的在原有表中添加一列来增加一个主观条件数据，但是该数据对针对原始数据库创建的应用系统而言完全透明，不能起到任何的作用。当然有人会提出在这种情况下使用NtoN的关系，然而多对多关系往往是导致数据库性能降到红线以下，或数据冗余失效的罪魁祸首，那么存不存在不用数据库建立多对多关系又能解决A君需求的方式呢？让我们再把目光聚焦到那个神奇的集合。如果X、Y、Z、W都是2的N次幂（N值不同），那么他们的位运算存在一些有意思的特殊规律（可以通过这类数字和位运算的运算法则证明）：1：X|Y|Z=D,则D实质是X+Y+Z的和2：X|Y|Z=D，则D&X=X，D&Y=Y，D&Z=Z，D&W=0；3：X|Y|Z=D，则DZ=X|Y有了这三个运算规律，我们就可以将其应用在主观条件类问题中，方便的实现我们的需求。在设计A君的旅游业务逻辑是，将原有数据拆分成两个两列的表：条件表：条件逻辑值是否为女性1是否小于25岁2是否轻于100KG4员工信息表：员工逻辑值E17（1|2|4）E25（1|4）E36（2|4）要判定某一个员工是否满足其中的主观条件，只需要将员工的逻辑值与条件值做位与运算，如果结果不为0，则说明条件满足，结果为0则条件不满足，而如果由于某员工一顿用膳过度导致超出第三个条件，那么只需要将原有条件值与第三个条件逻辑值做异或即可。另外如此设计带来的一个附加效果就是数据存放了大量逻辑数值，让人很难直接猜透其作用。有的时候数据保护就是这么简单。在游戏应用中，处理控制逻辑又是一个典型的“主观条件类问题”，键盘按键或触控控制是客观存在的，然而是否按下、拖拽等由软件使用者主观确定。如何方便快捷的识别用户的操作是游戏中最简单但是也是尤为重要的一个优化环节。在之前，大家可能会针对每个控制按钮设定一个布尔值来表示该控制键是否被按下，然而这种方式对于受限设备而言可能是一种灾难，因为它需要占用大量的固定存储空间。事实上，布尔值本身只有真、假两个状态，因此只需一位便能表示其所有取值，因此要优化此类操作，利用上文介绍的方式即可对功能占用的存储空间做出优化。例如我们为“上”、“下”、“左”、“右”四个控制分别赋予1，2，4，8几个逻辑值，在整个程序中只需要定义一个变量（state，初始值为0）来保存当前的控制状态即可，当按下“上”控制键时，只需要将当前的state与代表控制键的逻辑值1进行位或，而判定是否存在“上”的逻辑控制状态时，只需要用state与代表控制键的逻辑值进行位与，如果结果非0，说明按键已被按下，当“上”键被抬起时，state与1做异或即可消除逻辑控制