L
liguang
Unregistered / Unconfirmed
GUEST, unregistred user!
在撰写类时,对这个类的一些假设经常会象是梦魇一样,挥之不去。
也许这话太抽象,下面具体举一个例子。
我需要撰写个服务器端使用的类,这个有这样一个特别,它会在构造的时候去检查外部的一
个标志,如果这个标志的值为TRUE那么,那么则允许调用这个类的public部分以实现特定的
的功能。如果这个标志的值为FALSE的话,那么我则应该采取一些手段使用户不能够实现只有
标志为TRUE的时候类才能够去执行的代码。
至于这里采取的手段,一般有两种,一种就是在这个类的每一个公有函数的入口处设置检查
标志(去检查这个标志是否被初始化为了TRUE),如果为TRUE的话,那么则执行具体的代码。
另一种可采取的手段,则是在构造函数当中抛出异常,以提示客户类初始化未成功(因为标
志为FALSE)。
这两种手段都对使用这个类的客户提出了一种假设。对于第一种手段来说,用户在未来每加
一个公有方法或者与公有方法有关的方法的时候,都需要在这个方法的入口处写入检查代码。
而对于第二种手段,则必须在每一个构造后对象的指针的地方都去检查这个指针是不是nil
如果这个指针是nil的话,那么则不允许用户调用这个指向所指向对象的方法。
当用户调用这个类新增的方法,来为客户程序增加新的功能的时候,它必须遵守这些假设所
提出的规则,这就象是给这个类安了一个定时炸弹一样,说不定什么时候这颗炸弹就会爆炸
(也许是当我几个月之后重新将这段代码翻出来修改,也许是一个新手加入我的项目组来对
我的代码进行修改的时候,值得注意的是,在这里文档并不是一个解决方法,好多程序员始
不善于从文档当中找到这类应该的问题)。
这类错误也是比较难以发现的,毕竟好多人发现代码可以按照他们的要求正确工作之后就停
止测试了,而忽略了可能出现的非正常环境(标志为FALSE)的情况。
当程序已经形成了一定的规模,再去调试这种问题,简直就是一件令人感觉到恐怖的事情。
小弟对此问题始终没有想到一个好的解决方案,所以这里将我自己的一些想法贴出来,还请
各位大侠们能够多多讨论,以得出一个此问题的正解。
也许这话太抽象,下面具体举一个例子。
我需要撰写个服务器端使用的类,这个有这样一个特别,它会在构造的时候去检查外部的一
个标志,如果这个标志的值为TRUE那么,那么则允许调用这个类的public部分以实现特定的
的功能。如果这个标志的值为FALSE的话,那么我则应该采取一些手段使用户不能够实现只有
标志为TRUE的时候类才能够去执行的代码。
至于这里采取的手段,一般有两种,一种就是在这个类的每一个公有函数的入口处设置检查
标志(去检查这个标志是否被初始化为了TRUE),如果为TRUE的话,那么则执行具体的代码。
另一种可采取的手段,则是在构造函数当中抛出异常,以提示客户类初始化未成功(因为标
志为FALSE)。
这两种手段都对使用这个类的客户提出了一种假设。对于第一种手段来说,用户在未来每加
一个公有方法或者与公有方法有关的方法的时候,都需要在这个方法的入口处写入检查代码。
而对于第二种手段,则必须在每一个构造后对象的指针的地方都去检查这个指针是不是nil
如果这个指针是nil的话,那么则不允许用户调用这个指向所指向对象的方法。
当用户调用这个类新增的方法,来为客户程序增加新的功能的时候,它必须遵守这些假设所
提出的规则,这就象是给这个类安了一个定时炸弹一样,说不定什么时候这颗炸弹就会爆炸
(也许是当我几个月之后重新将这段代码翻出来修改,也许是一个新手加入我的项目组来对
我的代码进行修改的时候,值得注意的是,在这里文档并不是一个解决方法,好多程序员始
不善于从文档当中找到这类应该的问题)。
这类错误也是比较难以发现的,毕竟好多人发现代码可以按照他们的要求正确工作之后就停
止测试了,而忽略了可能出现的非正常环境(标志为FALSE)的情况。
当程序已经形成了一定的规模,再去调试这种问题,简直就是一件令人感觉到恐怖的事情。
小弟对此问题始终没有想到一个好的解决方案,所以这里将我自己的一些想法贴出来,还请
各位大侠们能够多多讨论,以得出一个此问题的正解。