CSDN博客

img idilent

使用oo设计聊天室

发表于2004/7/11 10:59:00  2396人阅读

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)。

0 0

相关博文

我的热门文章

img
取 消
img