首先感謝這篇大神給的啟發
建議先去大神部落格下了解抽象類及介面的原理，應用。
其中，我認為最核心的，是設計上的，抽象類是一種由下及上的設計，它是你寫了好多個類，然後發現，明明有很多個方法都是一樣的，還重複寫了好幾個，既浪費資源，又不便於修改，所以把它們歸在一起，形成乙個父類，每乙個子類再去繼承父類，就可以get√這個方法，簡單輕便易於維護。畢竟工作和學習是不一樣的，在學校你寫完的就是寫完的沒有然後了，工作中三天兩頭的改著需求，只改一處和改一大堆最後可能還漏幾個類因為不常用沒想起來沒改，自然是只改乙個要容易的多。介面是由上而下的設計，在幹活之前，就定下來，它是有什麼功能的，需要實現什麼方法，這些個方法都需要什麼引數返回什麼型別實現什麼功能。感覺起來，舉個栗子，抽象類是我們幾個狐朋狗友是怎麼湊一堆的，發現我們的共同愛好，你沒有這個愛好，不好意思你不是我們這個圈子的，你自己去一邊玩；介面是大領導，領導說什麼就是什麼，領導讓可什麼標準怎麼幹，就得怎麼幹。
而且，乙個類中，除了方法，還有屬性和構造器，如果屬性相同，比如這幾個類都有個string name的屬性，那也完全可以一起送到父類中，這樣新寫的類要有這個屬性，直接繼承就可以擁有這個屬性（請注意不要在父類中把這個屬性定義成private的）,節約資源。而介面是及其抽象的，屬性其實並不算是個多麼抽象的東西，所以盡量還是不要定義在介面中。構造器也是，無參的不必說，如果有好幾個類的有參構造器是用的同樣幾個引數，那也完全可以放在父類中，這樣繼承父類的子類就直接擁有了這個有參構造器，不需要接連在幾個類中都寫上同樣的構造方法，尤其是命名還不一樣。介面顯然，是沒有構造器的。
實際應用中，個人傾向於介面，因為多實現嘛，如果某一天領導說，我覺得這裡可以新加乙個功能，你改改吧，你看了眼所有的實現都是由乙個抽象類定下來的，然後你在抽象父類中新增了這個方法，第二天領導又說，不行不行，其中有幾個模組我不要那個新增的功能。所以用介面就比較容易實現，先按照領導需求把介面定義好，誰要用這個功能，就實現這個介面，哪天說不要這個功能了，再取消實現就可以了。這種感覺起來形容就是抽象類是樹的主幹，輕易不要動，傷筋動骨的萬一出點什麼么蛾子挺麻煩的，介面是枝幹，想要隨時可以新增，不要了也隨時可以砍掉。
由於我們那個老專案中controller或者說action沒有基類，我只能做個個人猜測，我認為basecontroller如果存在，應該是個抽象類，因為沒有人可以說這控制器是幹什麼的，都是幹著幹著發現，幾乎所有的控制器都會有列表展示，這樣就抽出來乙個基類，這個基類當然也是可以沒有的，並不耽誤幹活，但是可能我對列表查詢命名叫/getlist，別人叫/getpage，還有人叫/tolist。。。。萬一給所有列表頁做修改，想找到哪個頁的哪個方法，那真是，呵呵。而且程式設計大家也都知道，不是所有人都寫注釋的，我就覺得我叫getlist簡單明瞭易懂擱誰看都是列表頁，那更是[手動再見].jpg。而且對於剛入職的可能分頁還研究不明白的時候，找乙個列表頁研究，真的是挺費勁的。
專案的下乙個層次是service。這個毫無疑問是介面。因為必然要實現的crud是肯定的。剩下其他方法就各有各的誰也礙不著誰了，service層現在基本都是service介面和serviceimpl的實現類。用介面做規範，不僅是強迫症看著舒服，過幾個月忘了之前幹過啥的時候改起來還是一樣的迅速。
新手小白的對大神指點的感想，可能說的並不準確，歡迎指點~
再次感謝大神寫的辣麼詳細！
abstract應用及抽象類
1.抽象類的定義 1.1 抽象類是一種模板模式。子類可以繼承這個模板進行擴充套件。1.2 通過抽象類，避免了子類設計的隨意性。抽象類可以定義抽象方法，子類繼承抽象類就必須實現這些抽象方法才能進行例項化。2.格式 abstract class 類名稱 抽象方法格式 許可權修飾符 abstract 返回...
抽象類的定義及應用
1.抽象類不可以例項化。抽象方法是乙個模板或約束，避免了子類的隨意性，要實現它的類就必須重寫它的方法，除非子類也是抽象類。1.被關鍵字abstract修飾。2.抽象方法沒有方法體。public abstract void 方法名 public abstact void eat 定義抽象方法 抽象方法...
抽象方法 抽象類 介面 介面和抽象類的區別
某個父類只知道子類因該包含什麼樣的方法，無法知道這些子類如何實現這些方法。抽象類包含該方法但沒有對該方法的具體實現。有抽象方法的類只能被定義為抽象類，抽象類裡可以沒有抽象方法。抽象方法和抽象類的規則 public abstract class shape private string color p...