我記得在之前xx大型的互聯網公司，該公司只能算是很僞的互聯網公司，以業務爲主，非技術指導的公司，所以裏面的寫業務的人員水平也是參差不齊，代碼在不停地重構，沒過多久又會發現代碼的維護難度在增加，然後又是重構，出現了惡性循環。每次來了新需求，都會頭疼得緊，擔心需求的改變會對上一個版本有很大的衝擊。今天來介紹下該業務代碼簡單的架構知識。
先介紹下該代碼設計的背景知識。因爲是app的服務端代碼，所以需要支持每一個客戶端的代碼，也就是說，每一個版本的開發都必須支持上一個版本。所以之前的代碼裏面不時會出現if(dataversion>xx){}else{}，混亂不堪。最後在領導的主持下，決定對代碼進行一次重構，以適應這種快速迭代的過程。最後經過一個版本的時間，出來了一個新的架構：花了一個粗糙的圖，基本的意思相信大家都能看的明白：每個版本的業務代碼都會繼承上一個版本的code，如果對上一個版本有修改或者增加需求的話，直接override掉父類的方法。
其實這種做法極大地違背了里氏替換原則：即父類被子類修改掉了。這也造成了代碼的極度膨脹，以及混亂，讓新人對代碼的瞭解增加了很大的難度，因爲大家不知道，該功能是否在前一個版本被重寫掉。所以個人認爲可以如下的架構
這樣的話，就不會對之前的類進行修改，那有些人會問，這樣寫的話不就會導致abstract類的膨脹以及修改。我的回答是我們這時候就需要遵守另外一個原則了，職責單一原則。對於每一個功能都能夠單一出來，版本迭代的大部分情況下，就只需增加新的功能，而不會去修改前一個版本的內容，如果對前一個版本有改動的話，只需新增一個分支。我們始終要遵守的主旨是：對非抽象方法不修改。
個人拙見，請勿見笑！