黎克特制替換原則在現實中的應用

我記得在之前xx大型的網際網路公司，該公司只能算是很偽的網際網路公司，以業務為主，非技術指導的公司，所以裡面的寫業務的人員水平也是參差不齊，**在不停地重構，沒過多久又會發現**的維護難度在增加，然後又是重構，出現了惡性迴圈。每次來了新需求，都會頭疼得緊，擔心需求的改變會對上乙個版本有很大的衝擊。今天來介紹下該業務**簡單的架構知識。

其實這種做法極大地違背了黎克特制替換原則：即父類被子類修改掉了。這也造成了**的極度膨脹，以及混亂，讓新人對**的了解增加了很大的難度，因為大家不知道，該功能是否在前乙個版本被重寫掉。所以個人認為可以如下的架構

這樣的話，就不會對之前的類進行修改，那有些人會問，這樣寫的話不就會導致abstract類的膨脹以及修改。我的回答是我們這時候就需要遵守另外乙個原則了，職責單一原則。對於每乙個功能都能夠單一出來，版本迭代的大部分情況下，就只需增加新的功能，而不會去修改前乙個版本的內容，如果對前乙個版本有改動的話，只需新增乙個分支。我們始終要遵守的主旨是：對非抽象方法不修改。