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

模板設計模式：

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

• 抽象方法：父類中只聲明但不加以實現，而是定義好規範，而後由它的子類去實現。
• 模版方法：由抽象類聲明並加以實現。通常來講，模版方法調用抽象方法來完成主要的邏輯功能，而且，模版方法大多會定義爲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