以练代学设计模式 — FTP文件管理项目看，未来的博客-ftp采用的设计模式

不知不觉项目接近尾声，期间画了不少设计图，把能用上的设计模式都用上了。
今天来盘点一下。

主心骨：中介者模式

这次项目呢，我的想法是将各服务器分布与不同的主机上，所以采用TCP流进行进程间通信，但是呢，实现的时候我就发现，如果要将需要通信的服务器两两相连，且不说繁琐，怎么拓展？
于是我绞尽脑汁，想起来了中介者模式，于是有了下面这张图：

工程运行的时候，先启动中控服务器，中控服务器会用accept的方式接收来自各边缘服务器的连接。
边缘服务器连上中控服务器之后，会发一个自认身份的包给中控服务器，完成注册。
此后，通过注册的服务器向中控服务器发送的包，只需要在包头中注明包是给哪个服务器的即可由中控服务器转交。

往后，如果需要再添置服务器，也只需将新服务器连入中控服务器，自认身份即可。

拨云见日：责任链模式

负责和客户端建立连接的前置服务器，以及中控服务器，以及将来需要面对大量四面八方消息的服务器，肯定要用到文件描述符监听模型，我用epoll。
秉着“单一职责原则”，我认为epoll只需要且只能监听文件描述符，但是它不应该知道消息内容，更不应该对消息进行处理。
这个问题确实也困扰了我，我想了好久，因为我以前的做法都是epoll收到消息后，判断是哪个地方来的消息，如果是监听套接字，则判定是有新连接上来，处理连接（这里就需要将网络连接模块和epoll模块放在一起，这是其一）；如果是通信套接字（客户端）来的消息，那么就是客户端有消息上来，还要判断是否空包（空包为客户端掉线，需要处理），若不是空包，则对包进行一个基本的判断（这里就需要解压包模块的介入，这是其二），之后将包发往中控服务器（这里就需要进程间通信模块的介入，这是其三）；对包的处理与转发还使用了小型线程池（这就需要线程池模块的参与，这是其四），此外，还有日志模块和心跳检测模块，这么多东西，如今一锅炖在epoll模型中，成何体统？
但是又有什么办法呢？请求来了，自然是要回应的啊，要回应，就需要各个模块之间的配合了，我思来想去，想到了责任链模式。

我以前一直觉得这个模式简直是鸡肋，但是这次之后我改观了，没有鸡肋的设计模式，只有鸡肋的设计师。设计模式的优势是什么？

• 将请求和处理分开。
• 请求者可以不知道是谁处理了，处理者也不用知道请求者的全貌。
• 两者解耦，提高系统的灵活性。

于是便有了以下这张图，也正是这张图吸引了听我讲这个项目设计的朋友：

图我是不会再解释的，代码也不会放出来，因为我在我的日报博客中已经讲得清楚了。

四面开花：模板方法模式

解压包模块和数据库模块可是两个最不稳定的模块了，因为这两个模块会经常需要进行拓展，它们不像epoll、进程间通信、文件管理等模块，定下来就基本定下来了，只要要拓展新业务，肯定要加协议，再加数据库功能，如果将模块写死，便无法自由拓展。我问过不少朋他们如何处理这种情况，他们的回答基本都是一致的：写完就完了，拓什么展？非要拓展，拆开重写。

这个问题并没有困扰我，这个问题很简单的：依赖倒置原则，这是我很喜欢的一个原则，面向接口编程，只要我将接口定下来了，后面的拓展只要继承父类，拓展新接口便可。
于是，图是这样的：

数据库还插了单例模式，那小玩意儿就不说了。

其他小图

再随便放几张叫不出模式的图吧，不过，面向接口编程是真的利于拓展，伸缩自如哦。

润滑油：服务器间连接

只给你看接口：线程池模块

整体流程图

太长了，就分左右两块咯。