0808从server端的main.processor.go Processor.serverProcessMes()方法探究UserProcess、smsProcess以及各类mes包，他们的协调运作方式以及差异性

serverProcessMes()方法：

func (this *Processor) serverProcessMes(mes *message.Message) (err error) {

//看看是否能接收到客户端发送的群发的消息
fmt.Println("mes=", mes)

switch mes.Type {
	case message.LoginMesType :
	   //处理登录登录
	   //创建一个UserProcess实例
		up := &process2.UserProcess{
			Conn : this.Conn,
		}
		err = up.ServerProcessLogin(mes)
	case message.RegisterMesType :
	   //处理注册
	   up := &process2.UserProcess{
			Conn : this.Conn,
		}
		err = up.ServerProcessRegister(mes) // type : data
	case message.SmsMesType :
		//创建一个SmsProcess实例完成转发群聊消息.
		smsProcess := &process2.SmsProcess{}
		smsProcess.SendGroupMes(mes)
	default :
	   fmt.Println("消息类型不存在，无法处理...")
}
return 
}

底层逻辑是基于传来的原始数据反序列化后所的mes.type的不同调用对应的服务

可以理解成这是一种点对点的调用就像是gin框架项目的router层，不同的某一个网址会去调用某一个与之唯一对应的控制器。或者说是业务service

这些业务service有很多，当多到一定数量时，就可以对他们进行抽象

ps：再次理解一下抽象与封装的区别：  
         抽象
         处理大而复杂的问题的重要手段是抽象，强调事物本质的东西。 
         对程序抽象而言，一个语言结构的抽象强调的是该结构外部可观察的行为，与该结构的内部实现无关。
         抽象包括过程抽象和数据抽象。

         封装
         封装是把一个语言结构的具体实现细节作为一个黑匣子对该结构的使用者隐藏起来的一种机制。
         从而符合信息隐藏原则。
         封装包括过程封装和数据封装。

         区别
         封装考虑内部实现，抽象考虑的是外部行为
         封装是屏蔽细节，抽象是提取共性

抽象的结果于是就形成了不同的porcess，如userProcess、smsProcess

这里或许可以开拓下思路（这是我自己辖总结的）：

微观抽象动机与宏观抽象动机：

宏观抽象动机是指那些基于显示世界认知的抽象动机，比如需要涉及一只猫，或者一个锤子，他显而易见需要被设计成一个类，这个类具有猫/锤子所拥有的特性(比如埋屎，敲钉子)，有些神似java的一切皆对象特性

微观抽象动机是只那些在写代码的过程中，写出了很多地位一致，可以归类的函数或方法，这些方法中的某几个具有相同的特性，所以必须把他们单独提出来

server端的里的userProcess于smsProcess就符合微观抽象动机。

我再去看下client，是的client的userProcess与smsProcess同样属于微观抽象动机。

对比SmsProcess.SendGroupMes()方法与 UserProcess.Register()方法，先请看所有的消息类型：

const (
LoginMesType 			= "LoginMes"
LoginResMesType			= "LoginResMes"
RegisterMesType			= "RegisterMes"
RegisterResMesType 		= "RegisterResMes"
NotifyUserStatusMesType = "NotifyUserStatusMes"
SmsMesType				= "SmsMes"
)

重点或许在于想明白（Login和Register）事件是否属于sms事件(sms是其两者的超集)？还是说login与register是user实体的方法，sms是sms的方法，两者独立存在？

在此我先想明白一点，那就是sms并不是通过transfor进行数据传输所得到的“信息”（原始字节数组，或原始字节数组反序列化后所的的实体）

而是将原始数据进行了一次“类型断言”后才明确了这端原始数据是具有“sms”属性的。

同样的，有些原始数据进行“类型断言”后，会判断出他具有"user"属性

0808-15:20先想到这里，缓缓脑子吧

0808-17:12继续，这里的遇到的问题本质在于，user可以发出登陆动作，可以发出注册动作，也可以发出发送消息的动作，但是为什么从书写上看起来，sms这个“实体”却与“user”的地位一致了呢，明明sms应该是被user所操作的对象啊，虽然还想不明白，但是直觉上更应该属于上下集关系啊！！！

到目前为止分析的没什么问题，现在思路更加清晰了，sms属性与user属性其实都属于用户（英文名也是user，但是不是user属性的user，我懂得）的“两类动作”

用网络游戏举例子会更为形象：相当于玩家的注册与登陆，以及游戏中与好友聊天，这两类事。

在抽象逻辑思路上，sms与user这两“类”“动作”都是属于用户的，用户是最初的宏观抽象实体，sms和user是这个实体符合微观抽象套路，或者说是用户的所有动作中，抽象出的两类动作，还是拿网络游戏举例更为贴切，除了玩家的登陆注册属于一类，玩家间的通信属于一类，玩家间的交易也属于一类，玩家在游戏地图中的移动坐标相关操作也属于一类

重点：

1.范例中用userProcess与smsProcess这两个名字的书写方式欠妥，去问问源妹应该起什么名字更好

2.再去问问源妹对于某个实体，如人，的某类动作，如学习，挣钱，当今编程标准套路上是否也可以抽象成一个类，怎么给这种“动词”类在名称长给一个统一且容易区分的表示

3.可以用纯粹的接口语法将这两个“动词”类超集出外层的接口“user”，具体参照golang的socket模块源代码中，tcpConn、udpConn所对应出的超集Conn接口的操作

4.模仿源妹项目的java工程写法，先建立一个userProcess层文件夹，里面有个userProcessinter.go源文件，写一个接口，如“type User interface{}”，再写另外一个或多个.go文件，内部去实现所谓的userProcess和smsProcess结构体，让这两个结构体实现User接口，从而实现golang语言真正意义上的面向对象思想