编程中用不好重载就别用！关于重载逼到人发疯的案例！

“重载”会逼疯一个程序员吗？会！当重载在代码中无处不在时，真的会让一个接手他人代码的程序员分分钟陷入崩溃！重载出现的本意是当一个函数的默认实现满足不了现实需求的时候，使用重‍载则可以直接打破函数原有逻辑或者在原有逻辑上追加逻辑，大大方便了程序的扩展性，但是，我们公司有一个“大牛”他的重载用法，我看了真的很难受！

先说下重载的用法，首先你得继承一个基类，这个基类中需要定义一个“虚方法”，大多数编程语言中，虚方法需要使用virtual关键字来装饰，然后继承这个基类的实体类需要重载这个虚方法，一般使用protected override关键字来声明重载。

当然，虚方法中你可以定义一些基础实现，也可以完全不用实现任何逻辑，但是，不实现任何逻辑的话，完全只为了让外部重载这种用法不建议，因为这样的话，你完全可以不用定义基类和虚方法，声明一个接口就完全符合你的要求了！

我们公司的“大牛”使用虚方法的原因就是他想在某些操作中统一去执行一些东西，比如说一些确定和取消按钮，当点击时需要关闭窗口或者页面，所以，但凡是按钮的确认和取消功能他都继承了含有虚方法的基类，然后直接调用重载方法去执行页面的关闭逻辑！

乍一看好像没什么毛病，基类的结构也很简单，里面有两个虚方法，一个确认方法，一个取消方法，每个需方法里面只加了一行代码，用来执行关闭窗口或者页面的委托（或者说逻辑）。

如果你直接调用虚方法的重载实现我都没什么话说，主要是在虚方法的基类基础上又加了两个转发函数，外部在调用虚方法时不直接调用，而是先调用两个转发函数，由转发函数去执行基类虚方法的实现！

他这么做的原因是因为代码框架中确定和取消按钮必须先实现代码框架定义的系统基类中的两个虚方法，分别是确定和取消。

这么一来，其实他自己定义的基类和系统基类中的虚方法其实就冲突了，而为了硬调用他自己写的基类，因此就有了上面所说的转发函数。

这两个转发函数是做什么用的呢？其实道理也很简单，因为代码框架要求确定和取消必须先实现系统函数，因此，他在自己写的基类中线定义了一个系统函数的实现，这样确定和取消按钮就可以直接调用这个实现。

但是，光调用实现不行，自己定义的虚方法也需要实现，因此，在这个实现的基础上，又调用了对应的虚方法，在前端层面，也就是直接调用了虚方法的重载！

是不是很绕？我在看这段代码的时候，其实我也被绕了，虽然道理很简单，但是这种“硬控”代码，我欣赏不来！

最主要的是，当我想要定位按钮的实现时，我只能定位到系统函数的实现，但是，因为系统函数的实现是被他写在虚方法的基类中的，因此，我在定位函数实现的时候首先会被定位到他自己实现的函数基类中。

如果此时你是第一次看他的代码，你会完全摸不着头脑，因为你到现在还没发现函数的真正实现直到我去仔细观赏他在基类里面写的代码，我才知道：哦，原来他是通过调用这个函数，然后去调用那个虚方法的实现的，所以，我应该去前端找这个名字的虚方法的对应的方法实现！

能明白我的纠结点吗？比如说我要干一件事情，A明明知道我需要干什么事情，当我去问A时，A说他按照流程，得先让我去B那过一下，由B把任务发布给我，然后我到了B那以后，B告诉我，我的任务就是去A那执行！

能明白吗？B的作用只是中转！且如果不经过B，A是不会告诉我具体应该执行什么东西的！

如果代码中到处都充斥着这种代码，那我在阅读代码时就需要来来回回折腾：先定位方法-定位到基类-在基类里面找方法的虚方法-回到原方法去找虚方法的实现！

除非你对这套代码很熟，否则一定会被代码给绕进去。

我想了很久，他这么干的意图是什么，最后，我没有看到任何好处，只有一点，那就是的确代码变得优雅了。

首先，我们公司做的都是非标自动化项目，排除一些常用的硬件、通讯协议、UI我们会封装成库外，其他的基本上每个项目的代码逻辑都不一样，而且，后续再动代码的可能性极小，即使是客户想要新增功能，也不会出现大改的情况。

反而是一个项目代码部署出去可能等第二次客户要求增加功能时，因为我们这个行业程序员流动性比较大，因此，到那个时候当初写这套代码的人可能都不在了！

因此，代码的可读性是最重要的，代码的可读性上来了，应对突发状况的反应时间也就会很快，也会减少客户那边停机的损失。

结语

所以，别扯什么设计模式，有些时候，代码优雅的能开香槟，也不及让一个刚毕业的程序员能看懂来得实际！而一般维护这些已经交付的项目的人，恰恰就是那些经验稍浅一些的程序员！

所以，我最后叹了一口气，因为我改变不了什么，代码本身是来解决问题的，但是有些时候代码写得太通俗易懂反而会被人说成“幼稚”、“不够优雅”。