模板設計模式：

模版方法模式由一個抽象類和一個（或一組）實現類通過繼承結構組成，抽象類中的方法分為三種：

• 抽象方法：父類中只聲明但不加以實現，而是定義好規範，然後由它的子類去實現。
• 模版方法：由抽象類聲明並加以實現。一般來說，模版方法調用抽象方法來完成主要的邏輯功能，並且，模版方法大多會定義為final類型，指明主要的邏輯功能在子類中不能被重寫。
• 鉤子方法：由抽象類聲明並加以實現。但是子類可以去擴展，子類可以通過擴展鉤子方法來影響模版方法的邏輯。 抽象類的任務是搭建邏輯的框架，通常由經驗豐富的人員編寫，因為抽象類的好壞直接決定了程序是否穩定性。 實現類用來實現細節。抽象類中的模版方法正是通過實現類擴展的方法來完成業務邏輯。只要實現類中的擴展方法通過了單元測試，在模版方法正確的前提下，整體功能一般不會出現大的錯誤。

架構中經常使用的一種設計模式，很好的發揮了面向抽象程序設計，實現了“高類聚，低耦合”的架構思想。所以非常值得研究，學習和實踐。

開篇：跑題時間

雖然要跑題也先放上幾張來源於網絡的PPT正示一下主題，免得一下跑題太遠收不回來。

開始正式跑題了！這篇文章不想只談技術，一半當成總結吧。話說但凡愛裝逼的老碼農無不一張口設計模式、AOP、IOC（DI）等名詞成天掛在口上。其實技術和工作年限沒有太直接的聯系，你沒幹上架構師的活（崗位），說的吹的再順溜也等於是無用功。我幹程序員頭三年是做傳統的行業管理軟件“酒店管理系統”，當時是使用Delphi+Oracle做的，當年“聰明的程序員”都愛用Delphi，我一拖控件就是三年，一直都是面向過程設計，非科班出身，野生程序員，所以轉了C#之後又三年才開始慢慢面向對象設計和編程，但是我始終沒有面向抽象編程，也不明白為啥要使用接口、抽象類。C#用了五年的樣子開始學設計模式和經常重構了以為達到了“看山還是山，看水還是水”的境界，其實差老鼻子遠了。現在基本上.net用了有10年了，可惜一直沒有遇上大項目，一直在小作坊，小公司裏打轉。曾經有一次機會，團隊裏來了一個架構師，但當時離開了那個團隊，因為新來的總監套路太多太厲害，加上我沖撞了COO，作為非正式的部門經理被迫離職。一直沒有好好的進行架構設計，直到遇到現在的系統，非常佩服系統第一代的架構師，思想非常純正，項目裏也使用了模板設計模式。現在的系統架構沿用了十幾年了，一直很穩定，開放性很好，導致後續兩任架構師都超越不了，後來就一直沒有架構師了；現在公司的崗位目標也是工控架構師，但是看了半年的公開課，系統的學習了架構師知識體系這後，我認為架構師只能是養成的。話說最近醒悟了，不是ctrl+C,ctrl+V天天都這樣猛幹吧，老碼農得在他的崗位上提升自己的“領導力”，努力讓生態越來越好。

找不到哪裏看過的那張ctrl+C,ctrl+V一把梭的圖了，暫時用這個代替了。因為今天第二次看“C#/.Net架構師設計模式特訓【軟謀教育】”的模板設計模式的公開課，雖然公開課都是重復的反復的講那些知識，但是每看一次總是有新的心得。最近結合幾次實踐，越發覺得有寫文加深印象的必要，於是有了此篇隨筆。我的關註點是：為什麽架構師這麽重視這個模式，實踐意義在哪裏？作為一個油膩的中年大叔看來必須有點追求了，經常性的口是心非，不按套路出牌，不按計劃不走尋常路...,你以為多特別其實一直很失敗。本來準備寫個年終總結的，但是好久都沒有立長誌了，一直都沒按計劃來。呵呵。其實是有計劃的，只是實現起來是跨年的，身上背了幾十萬債務...好吧還是收回來，別倒苦水了。我只是說任何時候都不能有不腳踏實地的理由，應該不浮躁，每天進步一點點吧。

主題之普通方法/虛方法/抽象方法/

這是一篇沒有寫完的隨筆，最近工作比較忙，現在想放棄了。不寫了，具體案例其實另外兩篇隨筆已經寫了，感興趣可以看看：

http://www.cnblogs.com/datacool/p/datacool_2017_pda.html

http://www.cnblogs.com/datacool/p/datacool_2017_gdi.html

C#模板設計模式使用和學習心得