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