我记得在之前xx大型的互联网公司，该公司只能算是很伪的互联网公司，以业务为主，非技术指导的公司，所以里面的写业务的人员水平也是参差不齐，代码在不停地重构，没过多久又会发现代码的维护难度在增加，然后又是重构，出现了恶性循环。每次来了新需求，都会头疼得紧，担心需求的改变会对上一个版本有很大的冲击。今天来介绍下该业务代码简单的架构知识。

先介绍下该代码设计的背景知识。因为是app的服务端代码，所以需要支持每一个客户端的代码，也就是说，每一个版本的开发都必须支持上一个版本。所以之前的代码里面不时会出现if(dataversion>xx){}else{}，混乱不堪。最后在领导的主持下，决定对代码进行一次重构，以适应这种快速迭代的过程。最后经过一个版本的时间，出来了一个新的架构：花了一个粗糙的图，基本的意思相信大家都能看的明白：每个版本的业务代码都会继承上一个版本的code，如果对上一个版本有修改或者增加需求的话，直接override掉父类的方法。

其实这种做法极大地违背了里氏替换原则：即父类被子类修改掉了。这也造成了代码的极度膨胀，以及混乱，让新人对代码的了解增加了很大的难度，因为大家不知道，该功能是否在前一个版本被重写掉。所以个人认为可以如下的架构

这样的话，就不会对之前的类进行修改，那有些人会问，这样写的话不就会导致abstract类的膨胀以及修改。我的回答是我们这时候就需要遵守另外一个原则了，职责单一原则。对于每一个功能都能够单一出来，版本迭代的大部分情况下，就只需增加新的功能，而不会去修改前一个版本的内容，如果对前一个版本有改动的话，只需新增一个分支。我们始终要遵守的主旨是：对非抽象方法不修改。

个人拙见，请勿见笑！