通信总结--走了三天，又回到了原点

 

    这是三天来一直困扰我的问题，在做程序时，我应该是一步一步走，怎样能做出效果就怎样写代码，还是思考再三，设计出一种好的程序结构，试程序具有更好的扩展性，而且不需要传递很多参数。

    其实，这两种思路都有利有弊。第一种思路的好处是你很快就能达到目的，看到成果，然后可以发挥自己的想象力去做各种好看好玩的东西；缺点是这样写出来的程序往往逻辑混乱，结构糟糕，一旦你要改动某一处，就会有很多地方都需要改动，到时候容易把程序搞成一团浆糊。

    

    第二种思路的好处可能是你做的程序会很简洁明了，也很容易扩展和修改，你对程序的理解也会更透彻；但缺点是你前期会花比较多的时间且进展缓慢，最糟的是你想了半天也想不出好的设计思路，或者你以为很不错的思路，一去执行（写代码）就发现根本不是这么回事。在你花了好几个小时甚至几天还没有多少进展，看着别人一个个华丽的功能实现啦，你却只有干瞪眼的分，那时真是想死的心都有啦，心浮气躁，没有信心做下去啦（我现在就是这样）。

 

    我觉得，对于我们初学者来说，一开始还是尽量把功能实现的好，初步对所做的程序有个概念，有了一些第一手资料，再去设计会有底一点；另一方面，做出一些看得见的东西会有成就感，让自己更有信心。如果要去设计的话，还是找人或者和团队一起商量着干，一个人的思维毕竟有局限，尤其是自己一个人苦思未果的时候，最好不要埋着头硬干，这样收效甚微。（血的代价啊）

 

 

 

     在做程序时遇到的最大的麻烦就要数在读取信息线程中读到一条完整信息后如何处理信息的问题。由于这个线程要负责读取各种类型的信息（文字，图形……），所以我们不在线程外部不知道它什么时候读完一条信息，也不知道这条信息是什么类型，所以很难再线程外部处理读到的信息。比较靠谱的是在线程里处理，一旦读好一条信息，就马上处理（在文本框里显示读到的文字，在画图板上画出图形……），但这样会需要给线程传入不少东西（文本框，画布……），先不说程序扩展时的麻烦，本来就要传入不少参数，构造方法都老长老长啦！

               

这是我的服务器流程图：


 
 

 

     想了好久，想了好多办法，也实实在在地试过几种，都不行，最后灵光一现，想到一种不错的办法。由于要传的参数很多，我就把它们“集成”起来，把几个关联的参数作为一个类的属性，然后再在这个类里写获取这些属性的方法。比如把所有通信工具（文字聊天，联机画板……）放到一个“工具箱”里，到时只要在工具箱对象里新建各种通信工具的对象，然后再把工具箱对象传到读取信息线程里面就行了。

 
                                                                                                                                                     通信工具与读取线程流程图

 
              通信，读写信息，处理信息的流程图