最先实现的就是算法的实现。
需求：碰杠胡 ，不能吃 ，不能听 ，仅仅能自摸胡，当中癞子能够做随意牌可是不能碰和杠。
写的时候还不会玩麻将，还是老板教的。^_^
最麻烦的是胡牌算法。之前搜到的都是不包括癞子正常的胡牌，用的是%3余2，当中余数2就是余的将的意思。
可是有癞子就不能这么用了。仅仅好自己写一个了。
一个有136张牌，万，饼，条，东西南北中发白34种牌。
有四个癞子是直接就胡牌的，最坏的情况是有3个癞子，可是假设遍历一遍不用逻辑推断就有34X34X34接近4万次.
想一下假设能胡牌，最坏的情况下是在最后一次推断能胡牌，那之前的近4万次的推断都是浪费的。
这里转变一下思维，就是有目的的按需所取成胡牌所须要的癞子个数，而不是盲目遍历再推断胡牌。
算法的正确性：假设想胡牌必定是三扑一将（正常胡牌）。当中扑指的是顺子或者三重牌（比方 一饼二饼三饼 或者东风东风东风）。将指的是两个重牌。
四种情况：
1.假如将在【万】里面那么【饼】【条】【风】（包括中发白）必定是整扑。
2.假如将在【饼】里面那么【万】【条】【风】（包括中发白）必定是整扑。
3.假如将在【条】里面那么【万】【饼】【风】（包括中发白）必定是整扑。
4.假如将在【风】里面（包括中发白）那么【万】【饼】【条】必定是整扑。
假如当前癞子的数目是curHunNum。
如今先获取【万】【饼】【条】【风】各自成为整扑所须要癞子的个数，假设是情况一。
needHunNum= 【饼】成为整扑须要癞子的个数+【条】成为整扑须要癞子的个数+【风】成为整扑须要癞子的个数;
假设hadHunNum = needHunNum - curHunNum； 假设hadHunNum<0 需求的比拥有的多 就不做推断。
否则就推断【万】中成为整扑一将须要的数目。
情况二三四依次类推。