多一分则肥少一分则瘦

最近在重构以前写的代码，希望更安全，更快，更优雅；

发现自己当时犯着可笑幼稚错误：

1，幼稚的过度编程：在写一个底层的资源管理的东西，在出错的时候我选择像dx函数一样返回一个handle，通过handle的数值来确认是什么问题；但是我的这个类规模不大，而且可以debug跟进去，所以这么麻烦的handle错误认证是杀鸡用牛刀，结果就是简单的类，看起来相对非常的麻烦；而dx handle是因为封装到库中，没法跟踪，而且规模比较大这样做不得已而且也合理；而我则是不假思索的去照搬--幼稚的过度编程；

2，清晰的构造逻辑：一个类的object的构建需要一些资源，如果这些资源分配不出来怎么办？是仍旧构建这个object，但是其任何action都成为空，还是干脆不构建；当然，我们没法给出一个通用的答案；但是常规来讲，一个object构建出来我们总是潜意识认为它是可以工作的，如果构建出来了却仍旧不能使用，那的确是伤脑筋增加复杂度的事情；我开始是在构造函数里去申请资源，却没有加空指针判断，结果crash，后来加了保护仍旧不好的结构；

3，指针的保护，判断，assert；

4，if...else:下面是典型的短见的行为：

 

enum QueryState
...{
    QueryBegin;
    QueryEnd;
};
 void Query(QueryState val)
...{
    if(val == QueryBegin)
    ...{
         ...;
    }else
    ...{
        ...;
    }
}

if...else讲非此即彼，适用于true,flase;NULL,非NULL;但是对于那个enum则不是如此，虽然目前是好用的，但是它的写法表达的是非此即彼，而不是类型的判断，尽管对，但是不准确；

仍旧应该用else if...

重构重构再重构，时间越长，理解越深刻，思路越清晰，最后写到“多一分则肥，少一分则瘦”