5/17/2010，6/12/2010

11:38 AM 6/12/2010
业务层需求
- 逻辑清晰：
    代码直接反映需求
    可以很复杂，但是要易维护
- 能快速开发
    业务逻辑变动太快   
- 避免出现业务层无关的实现细节
    严格内聚

实现层
    工具层
        - 使用简单
            不能给用户带来复杂性           
        - 强大
            支持各种相关功能，强内聚
        - 内部实现可以牺牲简单性
            难以避免
        - 可以带有技巧
            凡是与需求无关的好东西，都可以归结为技巧？
        - 重用性好，不需要最好
            需要有重用性，但是首要目标是满足用户需求

我认为表现层也属于业务层：
- 表现层也与领域强相关
- 之所以分离出表现层，是因为它：复杂，易变，职责明确
像UML一样：需求层，分析层，实现层

粗略想法：基于接口编程，业务层调用实现层的接口，每个层靠接口通信。
- 接口无实现，所以工作量小，快速
- 配以uml需求和分析模型，业务层可以很快完成
- 表示层用快速界面工具

9:38 AM 6/3/2010
项目的文件管理
    在项目的文件管理上，物理上的和vs工程里面逻辑上的树形结构，都可以增加上下文信息，减少冗余信息。物理上
    的树形结构加上名字空间就可以提高大量文件的可维护度。
    当然，物理上的文件结构存放在树形结构里，对应的vs逻辑目录结构也应该跟物理结构对应。
   
关于头文件include的问题
   
    类对应的cpp文件需要包含本类对应的头文件。物理上这两个文件几乎总是放在一个目录下面，所以，我们常常在
    本类的cpp文件里面不加路径就可以直接找到本类的头文件。这也不是太大的问题。
   
    但是，不够统一。如果要包含一个类，并且总是给出完整路径，那么就很统一。本类的cpp文件要包含本类的头
    文件也跟其他任何使用这个类时的用法完全一致。这样就非常统一了。
   
    统一带来的好处是易维护。最简单的，如果要全局字符串替换，一次替换就可以全部完成。

3:34 PM 5/24/2010
关于断言的使用场合
    断言是用于帮助程序在开发期间内定位错误的一个工具。虽然关于指针为空的断言看似多余，实则不是。使用空指针
    虽然系统会主动中断，但是却不能及早检测到错误的来源。
   
   
11:22 PM 5/17/2010
对于登陆调用来说，比如：Error* Login()；
可能的错误列表是：
- module not init
- not connected
- user not exist
- invalid pwd
- time out
...

这些错误可以分为3种类型：
- invalid usage by developer:
    invalid param, invalid seqence, uninitialized module, not logged in..
- user data invalid:
    invalid user name, invalid password, invalid birthday...
- application internal error:
    connection lost, time out...

对于第一种, 开发版本就应该解决；对于后2种，可以报告给用户并且提供解决的办法给用户。
如果从用例驱动的角度说，第一种错误就是系统自己的错误，而后2种属于外部错误，因为用户和网络都可以作为外部的
参与者。
还需要注意的是:
- 一个api调用可能产生多个错误。如果这些错误是不是瞬时的，可以考虑加上时间戳。
- 有些错误是可以分类的，比如注册用户错误就包括用户名存在，密码错误，日期错误等。这可以考虑使用异常，因为异
    常是OO的，可以建立抽象类和子类。否则，用错误码很难表示这种分层关系。

所以，得出的经验就是：
- 识别出系统的参与者，对于设计系统的错误处理策略也是至关重要
- 系统内部错误应该在系统内部解决而不应该干扰外部用户
- 用异常来处理错误有很多层次的情况比较好
- 错误处理不能小视