如果说前两年OO 还是个时尚词，现在的软件，程序恐怕都要挂上OO的标志了，其实在开发中我们也已经都自觉不自觉地使用OO，比如我们建立一个类，为这个类写方法，然后创建对象，执行对象方法。但是这就是面向对象了吗？最近看系统还是发现了不少问题：

　　就举一个例子

不只在一个地方看到这样的程序：

User u=new User();

u.name=t1.text;

u.password=t2.text;

if u.check (){

    …

} else {

   …

}

这其实是一个用户登陆的小Case，看起来这个代码也非常的简洁易懂，可是这５行代码就真没问题吗？（BTW:记得2004年底某个寒冷的夜晚我和喇叭就专门讨论过这个例子）

         u是一个用户，在执行完check方法以后就可以实现登陆。

         其实问题的关键是谁在负责u的验证？是u自己还是使用的system ?呵呵，每个用户都有check方法，而他们每次登陆都用自己的这个方法来验证自己？现实生活中真正的关系是否应该是这样呢？我们进入考场是我们自己check我们自己还是考场的负责人员呢？

         真正的关系应该是这样的：

系统当然有自己的用户管理机构（UserManager）,这个用户管理机构有专门验证用户的方式(checkUser)，如果验证通过会获得一个令牌(Token)。

那么我们是不是把简单的事情搞复杂了呢？还多出了一个UserManager !

当然不是，作为一个人事管理机构，指责中当然包括了注册新用户，注销用户，查找用户等等 ，那么想想看我们是否写过User.Add()这样的语句呢?现在再想这个Add应该再哪里？

吼吼，这里我不得不提到Noah 的WTSS，从工作原理和设计初衷上WTSS是绝对的好东东，不过在user的处理上Noah 没有用到OO或者用错了OO.(他使用的方式方法就u.Add(),u.check()…这其实严重导致了WTSS的升级扩展问题。

Why ？怎么扯到扩展问题了呢？

如果u是系统的认证用户，那么u就是数据持久层中的那个静态类的对象，也就是说他是数据库Users表中的一行，它能做什么或者说是干什么的呢？他当然是信息记录的载体，使用这个信息载体的地方是不定的。

就好象我在A公司工作，将来我很有可能在B ,C,D 公司工作，这些公司在使用的时候会有不同的方式和方法，这些方法是属于A,B,C,D公司的。

再拿u 举例子，如果将来要打印用户信息我们就加一个u.print 方法好吗？那不是要修改User这个类？这个类是我调用的，我只有.dll ,怎么办？

现在是不是有些了解呢？

我们应该这样吧：

　Ok ,结束！自己体会了～。