我也使用现成的服务器，如openfire，
我想实现的只是客户端。
那么客户端的设计可以怎么分？
比如界面和通讯分离？
本地数据的保存，系统平台的可扩展性等等。
大家是怎么看客户端的架构设计的？
一起讨论讨论
7 个解决方案
#1
面对同样的需求，可以有多种框架。
看你最终需求是如何的，比如哪些模块是相对稳定不变的，哪些模块是经常会发生变化的。
我经常把易变动的部分封装在一个模块中，同时各模块与层次尽量解耦，还要考虑不同模块的可复用性。
我的设计思路是，满足“今天”的需求，考虑“明天”的需求，不要管“后天”的需求。不然，过度设计，会带来成本，同时使系统的灵活性大大减弱。到了“后天”之后，再考虑得构。
看你最终需求是如何的，比如哪些模块是相对稳定不变的，哪些模块是经常会发生变化的。
我经常把易变动的部分封装在一个模块中，同时各模块与层次尽量解耦，还要考虑不同模块的可复用性。
我的设计思路是，满足“今天”的需求，考虑“明天”的需求，不要管“后天”的需求。不然，过度设计，会带来成本，同时使系统的灵活性大大减弱。到了“后天”之后，再考虑得构。
#2
可以参考pidgin
#3
界面和通讯分离，就是减少耦合，把界面和通讯做成各自独立的模块，两者之间通过一些定义的接口互相交换数据等。
服务器端尽量是各个客户端保持独立，客户端的增加，减少不会影响其他客户端
服务器端尽量是各个客户端保持独立，客户端的增加，减少不会影响其他客户端
#4
lz可以具体研究下QQ。
#5
#6
一般情况应该这样
满足“今天”的需求，考虑“明天”的需求，不管“后天”的需求
满足“今天”的需求，考虑“明天”的需求，不管“后天”的需求
#7
学习
顶一下
顶一下
#1
面对同样的需求，可以有多种框架。
看你最终需求是如何的，比如哪些模块是相对稳定不变的，哪些模块是经常会发生变化的。
我经常把易变动的部分封装在一个模块中，同时各模块与层次尽量解耦，还要考虑不同模块的可复用性。
我的设计思路是，满足“今天”的需求，考虑“明天”的需求，不要管“后天”的需求。不然，过度设计，会带来成本，同时使系统的灵活性大大减弱。到了“后天”之后，再考虑得构。
看你最终需求是如何的，比如哪些模块是相对稳定不变的，哪些模块是经常会发生变化的。
我经常把易变动的部分封装在一个模块中，同时各模块与层次尽量解耦，还要考虑不同模块的可复用性。
我的设计思路是，满足“今天”的需求，考虑“明天”的需求，不要管“后天”的需求。不然，过度设计，会带来成本，同时使系统的灵活性大大减弱。到了“后天”之后，再考虑得构。
#2
可以参考pidgin
#3
界面和通讯分离，就是减少耦合，把界面和通讯做成各自独立的模块，两者之间通过一些定义的接口互相交换数据等。
服务器端尽量是各个客户端保持独立，客户端的增加，减少不会影响其他客户端
服务器端尽量是各个客户端保持独立，客户端的增加，减少不会影响其他客户端
#4
lz可以具体研究下QQ。
#5
#6
一般情况应该这样
满足“今天”的需求，考虑“明天”的需求，不管“后天”的需求
满足“今天”的需求，考虑“明天”的需求，不管“后天”的需求
#7
学习
顶一下
顶一下