使用oo设计聊天室

OO对于现在的程序员来说是一个非常熟悉的概念，而OO也的确能够带给我们和我们的程序很多好处，代码的重用节约了大量的开发时间，而一个真正使用OO进行设计和编码的软件，也必将在升级和维护的过程中从OO方面受益匪浅。

然而OO对于大多数开发者（尤其是那些使用Delphi等高效工具的程序员）来说可能还仅仅停留在比较肤浅的认识阶段，往往在开发过程中只是简单的使用了开发工具提供的类，只是简单的对这些开发工具提供的类实现了重用，对于自己编写的类可能根本没有考虑到以后的重用（组件开发除外），也很少从以后升级维护的角度考虑对于OO的使用。当然这些论断只是从我的个人开发历程得出的推论，极有可能以偏概全，我写这篇文章的目的也不是来指导程序员的人生，我只是希望能够让更多的人从我的所想和所得中（虽然有可能是错误的）得到一些启示，避免走和我一样的弯路，当然也不排除读者读到最后发现这是一篇垃圾的可能，对于对这些读者造成的时间和精力的浪费表示深深的歉意。

在这里我也稍稍提一下我使用过的两种开发语言Java和Delphi（更应该说他是工具），我的程序开发是从Delphi开始的，Delphi这个工具的确非常强大，对于现在的我来说有些过于强大，他几乎让你停止思维，使我们的工作停留在拖拽控件的上。这的确提高了效率，但是同时也损失了别的东西，就是我们自己的类，在我使用Delphi的过程中，我很少考虑到该如何开发一个类，现在想来那时的开发是一种面向界面或者面向功能的开发，当时的开发文档是别人提供的，基本是也是这样的一种思路，文档有一个界面，接下去是描述该界面实现什么功能，其中根本没有提及关于类的东西，而自己的开发过程中也是习惯的创建窗体，对于单个unit的使用，基本上是用于提供共用函数和变量的。当然这样对开发工作好像没有带来什么坏处，但是对于我们自己的类的重用以及以后的维护却没有得到OO应该得到的好处。

Java却不同，它不允许非类的出现，也就是说不管你在写程序的时候又没有思考，你写的都是类，这就让我不得不去思考。当然，在开始的时候，几乎把类当作了包(package)来使用，很多类都是各种于某一功能相关的方法的牵强的组合，其中根本么有从重用和省级角度出发。所以我在这里想说的是，要成为一个好的程序员，写出好的程序，要不停的思考，而不是仅仅记住大量的API和找到解决问题的方法，我们需要的是更多的思考，目前是关于OO的思考（20年之后可能是对于其他的思考），思考如何通过OO来解决问题，并使之真正的从OO中受益。当然关于java的说明可能因为目前我的大部分开发主要集中在web端，和UI接触较少的原因，不知道如何开始接触大量的GUI后，还能不能保证自己这种思维的连续性。

又说了很多废话，现在言归正传。聊天室相信来看这篇文章的人都有一定了解，也可能有很多人甚至自己开发过，从功能上将基本上是这样的，一个人可以对另一个人说话，帖图片，还有一些其他的功能，比如管理员可以踢人等等。不没有读过聊天室的代码，但是我想如果我们使用java开发的话，我们首先要有一个user类，每一个在聊天室中聊天的人就是一个user的实例。很多人看到这里也许想，这还有什么讲的，把各个功能给user这个class就可以了，难道还有别的类吗？毫无疑问这个样可以解决问题，而且相信大部分都可以开发得出这样的代码，然而这样作业毫无疑问为以后带来的很多问题，如果我现在想改进这个聊天室，比如说打人，在聊天室里面两个人互相对打，按照上面的方法，我需要在为user这个class添加另外的方法，后来又要升级，可以在聊天室里面结婚......，于是这个user就变得越来越大，可以想象这是一个什么样的程序。（当然也有可能这个聊天室在第一次开发之后就不再改进，原因在于由于功能的陋没有人在这里聊天，哈哈我真不知道是该庆祝还是该做些别的）

如果有人真的这样开发的话，可能会发现其实讲话、踢人等这些方法有很类似，也就是说，除了他们的名字之外其它都是一样的，一样的返回值、一样的参数。这样我们就可以把它放入一个方法中，在这个方法中根据得到的数据进行判断，执行不同的动作，但是如果把这些动作仍然作为user的方法的话，仍不是一个很好的解决方法，我们得到的还是一个巨大无比的类，那么我们为什么不把动作作为一个对象来处理呢？也就是说我们在创建一个类名字叫做Action，user根据自己受到的参数创建相应的Action的实例，而至于这个Action有什么效果全部在Action自己内部处理中处理。而这个时候我们遇到两种解决方案，1、把所有的Action作为一个类来处理；2、把不同的Action作为不同的类。我认为后面的方案是一个比较好地解决方案，因为如果我们把所有的Action作为一个类来处理的话，我们只是把user中处理Action的部分转移到一个类里面，而随着系统的不断改进，这个类仍是无穷的增长。这样似乎并不是一个很好的改进，当然有一种情况可以使这个Action类在系统升级的情况下不发生变化，就是把所有的逻辑记录在数据库中，这样增加逻辑时只是增加数据库中的纪录，而Action的代码不会发生任何变化，不过如何实现这样的程序和数据库的设计，我想对现在来说还是一个比较大的挑战。现在我们看，如果我们使用不同的Action的类会造成这些类的使用上有一些不方便，而且我们在开发过程中会发现，这些类的提供的方法是一样的，都是带有一个to(user的实例)参数，这样我们就可以把这一方法作为一个接口(interface)doAble的方法，然后让我们的所有的action实现这个接口，同时在user调用这些action是，我们用doAble声明变量，用各个不同的action实例化。当然如果你愿意做得更完善一些的话，可以把action的实例化部分写成一个工厂类，这样传给这个工厂类一个参数，工厂类根据这个参数产生不同的实现doAble的Action对象。而user这个class根本不了解Action对象内部究竟是什么样的，他只需要执行这个Action就可以了。

这样的设计似乎更加符合面向对象的设计，我们来看一下这种设计方法对以后系统升级带来的好处，如果我们需要增加一个功能，我们需要的是添加一个新的类，当然这个类要实现doAble接口，然后如果我们写了一个工厂类的话，我们需要在这个工程类中加入相应的代码，用来根据合适的条件生成这个新的Action，而对于其他部分的代码可以说根本没有影响，如果我们想做得更加简单化，我们可以把工厂类中的逻辑写到一个配置文件中，在这个配置文件中我们记录两个参数一个是传递给工厂类生成Action方法的参数，一个是这个参数对应的Action的类的名字，这样我们就可以在增加Action时只修改配置文件，而工厂类的代码都不需要改动。(这一部分好像是根据struts的设计方案得到的)。

 

版权所有：idilent 网站转载请注明作者 其他转载方式请与作者联系(idilent@yahoo.com.cn)。