一段代码竟然包含了十几种业务逻辑，程序员：一个委托直接解耦！

公司一程序员有一段代码写得太乱了，总结下这段代码的逻辑那就是业务逻辑结束了，需要往很多地方写入业务结束的处理逻辑，而这个程序员对于业务结束的处理逻辑，我大概看了下，总共写了大概有3000行左右的代码，直接给我整崩溃了，原因是他把所有逻辑都写在了一起，但凡有一个逻辑写的有问题，代码都走不下去。

事情的起因是这个程序员写的软件总是在业务结束的时候出各种问题，改来改去，最后他自己都给改懵了，最后，项目经理看他脑子已经乱了，于是就让我帮忙看看他的代码，看看能不能帮他找出问题来。

他这段代码是写在一个工具类里面的，还好，他还知道封装一个工具类来整合业务结束的处理逻辑，但是一看代码行，着实给我吓了一跳，代码总共有3000多行！

据这个程序员所说，在业务逻辑结束以后，首先得往数据库里面写入日志，还得在本地写入文本日志，最后根据业务的结束状态，需要往外部发送业务逻辑的结束信号，还得在PLC里面写入数据和业务状态，最后我数了一下，前前后后，在这段业务结束的代码里面总共需要往本地或者外部发送十几种数据或者状态。

但是呢，其实业务结束的逻辑本身就几十行，后面近3000多行代码都是用来处理数据信号和数据存储以及状态的。

最后，虽然我们通过分析，解决了这段代码中的BUG，但是，面对这3000多行的代码，我实在忍不了，因为代码也得太臃肿、太耦合了！

于是我问他：“如果当中有一段逻辑不用了你会怎么办？”

他想了一会儿，但是也没想多久，告诉我：“只能把这段代码给注释了！”

然后我又问他：“如果这里面又要新增一部分逻辑，你又会怎么办？”

结果他说：“那就在现在的代码基础之上再插入新的逻辑代码！”

我就知道他会这么说，而且，他也只能这么干！

接着，我又问他：“现在你把所有的业务结束逻辑都写在了一块，万一系统里面有其他的界面需要知道业务结束的状态，你怎么办？”

他告诉我：“我在代码里面加了一个状态，其他页面只要监听这个状态，就可以了！”

于是我反问：“你会怎么做？”

他回答：“在页面上加一个定时器，然后一直读取存储状态的变量，发现值变了，就知道业务结束了！”

我无奈地拍了拍脑袋：“万一，我说万一，有十几二十甚至是上百个页面都需要知道这个状态，你难道要写十几二十甚至上百个计时器吗？”

这时候，他不说话了，于是我说：“事情不需要那么复杂，只需要一个委托就够了！”

委托（Delegate），在C#这门编程语言里面又称事件，简单得说，委托就是一种对事件的订阅！通过声明调用，可以将事件触发信号分发给订阅了委托的其他方法中！

比如说，现在代码中的业务逻辑结束了，我们可以声明一个委托，然后在业务逻辑结束时调用这个委托，这时候，只要外部代码订阅了这个委托，那么它们就会收到委托被执行的消息，具体来说，订阅委托实际上就是给委托一个执行方法，在委托被执行后，这个执行方法会一起被执行！

现在，在上述程序员写的业务结束的代码中集合了十几种需要处理的逻辑，这时候，我们可以在业务结束的代码里面声明一个委托，然后将这十几种需要处理的逻辑单独封装起来，然后订阅业务结束的委托，当委托被触发后，这十几种已经封装的逻辑块都将收到事件信号，逐一处理即可。

使用委托的好处在于它可以将繁复的业务逻辑模块化，从而提升代码的可读性和可维护性，而委托本身就是一种状态机制，因此，上述程序员写的状态字段的监听程序也就没必要写了，直接将委托本身当作状态或者使用委托参数的方式，把状态传递给订阅者即可。

结语

委托的概念其实很简单，其实就是“当发生某件事情的时候由事情的发生者告诉订阅者”，这跟我们手机上的消息推送机制很像，比如说当你关注了某个明星的账号，当这个明星的账号下面有了新的动态，你的手机就会在第一时间收到这个明星发送的最新动态。

有一些刚开始使用委托的程序员会觉得委托会增加代码的复杂性，但是，实际上用对了委托会感觉真香！