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