高内聚低耦合

高内聚低耦合 

1、内聚 
             是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系

2、耦合 
            是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以             及通过接口的数据

3、高内聚低耦合 
         是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要是看类的内聚性是否高，耦合度是否低。

内聚就是一个模块内各个元素彼此结合的紧密程度，高内聚就是一个模块内各个元素彼此结合的紧密程度高。

所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。

关键词：高内聚低耦合，网络消息，消息中间件
作者：码匠信龙

我所理解的高内聚是模块内部是独立完成某个单一的功能，尽可能的少而简单，也就是常说的单一责任原则。低耦合是各个模块之间相互独立存在，这样利于修改和组合。短期来看，并没有很明显的好处，甚至短期内会影响系统的开发进度，因为对开发设计人员提出了更高的要求，但长期来看，带来的好处是使程序更容易维护和修改。

在《由if-else,switch代替方案引起的思考》这篇文章里，有读者没太明白这种写法的好处(高内聚，低耦合), 当时没有展开来讲解。如果业务逻辑不复杂，只有几种情况时，其实用if-else或者switch更合适。下面通过个简单的例子来讲解：

这次，我们要写个客户端收到服务器返回的网络消息处理函数，换用函数封装case的逻辑处理代码，消息处理的伪代码如下

//代码示例1
void  NetMsgProc( message) 
{  
    switch (message)   
    {  
    case MSG_USER_LOGIN: //用户登录成功
        OnUserLogin();
        break;  
    case MSG_USER_SIGNIN://用户注册
        OnUserSignIn();
        break;  
    case MSG_USER_PAY_SUCCESS://用户支付成功
        OnUserPaySuccess();
        break;  
    case MSG_USER_PAY_FAIL://用户支付失败
         OnUserPayFail();  
         break;  
    default:  
         return 0;
    }  
    return 0;  
}

看上去，比原来例子要代码美观些了, 网络消息响应的代码没有耦合在消息处理函数里，可以分离在实际业务里。

在来看段python伪代码实现：

//代码示例2
messages = {}

#绑定消息处理函数和消息ID
messages[MSG_USER_LOGIN] = OnUserLogin()
messages[MSG_USER_SIGNIN] = OnUserSignIn()
messages[MSG_USER_PAY_SUCCESS] = OnUserPaySuccess()
messages[MSG_USER_PAY_FAIL] = OnUserPayFail()

...
def NetMsgProc(self,message):                  
    if message.type in messages.keys():              
        listener = messages[message.type]                                
        listener(message)

看上去两段代码量差不了多少。接下来改写上面这代码：

//代码示例3
messages = {}

#绑定消息处理函数
def NetMsgBind():
    messages[MSG_USER_LOGIN] = OnUserLogin()
    messages[MSG_USER_SIGNIN] = OnUserSignIn()
    messages[MSG_USER_PAY_SUCCESS] = OnUserPaySuccess()
    messages[MSG_USER_PAY_FAIL] = OnUserPayFail()

...
def NetMsgProc(self,message):                  
    if message.type in messages.keys():              
        listener = messages[message.type]                                
        listener(message)

看上去示例代码3和示例代码2差不多，只是封装为函数而已，没什么区别。注意了，别分神。如果改写下那个消息初始化函数，把消息ID和对应响应函数抽象出来，作为参数传入。

//代码示例4
messages = {}

#消息初始化函数
def NetMsgBind(self,msg_id,callback_fun):
    messages[msg_id] = callback_fun

...
def NetMsgProc(self,message):                  
    if message.type in messages.keys():              
        listener = messages[message.type]                                
        listener(message)

这时候你可以看到，网络消息处理函数，已经没有和消息响应函数有耦合了，而是可以分离到具体的业务逻辑代码里面写了。

例如用户支付功能的业务伪代码如下：

#代码示例5
#用户支付业务逻辑
#netManager是封装了代码示例4的网络消息处理类

def UserPay():
    netManager.NetSendMsg("MSG_USER_PAY",paydata);  //给服务器发送支付消息

def UserPayCallback():  //绑定支付相关的回调处理函数
    netManager.NetMsgBind( "MSG_USER_PAY_SUCCESS",OnUserPaySuccess);
    netManager.NetMsgBind( "MSG_USER_PAY_FAIL",OnUserPayFail);

def OnUserPaySuccess():
    dialog.show("支付成功!")
 
def OnUserPayFail():
    dialog.show("支付失败!") 

这样，实例代码4可以作为一个网络消息处理的核心模块，跟实际的业务逻辑没有关系，这个核心模块甚至可以作为其他业务逻辑的消息处理中间件，例如界面控件响应消息，数据库请求查询消息等。如果是用swich-case方式来写的话，实际的具体业务处理函数会耦合到里面。使用键值对映射响应函数后，可以进一步抽象，使得消息和响应函数绑定跟具体业务逻辑分离开来。

这样这个网络消息处理核心模块，小而美，只专注处理两件事情：
1.绑定消息ID的处理函数
2.服务器消息过来，调用相应消息响应函数

跟具体业务逻辑没有耦合，这样具体业务代码里写响应函数，代码维护起来更容易。如果多人协作开发一个项目时，用代码示例4方式，每个人如果有新增业务逻辑，只要修改他维护的业务逻辑代码，不需要修改核心模块，减少项目出错几率。

要掌握这种编程思想，写出短小而美的代码，我想只有通过不断的回过头去反复修改，反复推敲，反复提炼。就像工匠大师那样，用数十年的精湛技艺，反复打磨地原石，最终以呈现宝石极致美感。

版权声明:本文为博主原创，欢迎转载分享，只需注明作者与出处http://thinkingroom.me