|
设计: 人类通过劳动改造世界创造文明创造物质财富和精神财富而最基础最主要的创造活动是造物设计便是造物活动进行预先的计划可以把任何造物活动的计划技术和计划过程理解为设计意指有目标和计划的创作行为 模式:前人积累的经验的抽象和升华简单地说就是从不断重复出现的事件中发现和抽象出的规律是解决问题的经验的总结只要是一再重复出现的事物就可能存在某种模式 一般一听说别人是搞设计的都非常佩服无论是否是IT行业觉的做设计的总是能从全局出发均衡的考虑问题比起最底层的工作者来说总是高那么一点点 程序员都希望自己的程序写的代码结构强壮容易维护扩展性强而设计模式也许是实现这一想法的最好理论所以很多程序员(包括本人)都希望有自己的程序中用上那么一点点的设计模式即使作用并不那么明显也会有种成就感但是并不是所有的程序员都能非常容易的找到这样的机会虽然清楚种模式的定义但在具体的项目中并不知道应该如何来用 还有一种情况是当自己对设计模式的全部概念并不是特别清楚的时候例如建造者模式他们的程序中往往都应用到了某种模式只是没有太在意而已 Net中的StringBuilder就是应用了建造者模式 这里以我的经历来说明一下我以前在一个项目中开发了一个分页控件 但我是在学习了建造者模式后才发现是应用了模式 我们知道所有的控件包括用户控件和自定义控件它们都是继承自Control类在自定义控件中我重写了它的如下些方法: Code //重写服务器控件的输出标记 protectedoverrideHtmlTextWriterTagTagKey { get { returnHtmlTextWriterTagDiv; } } //重写服务器控件内容输出前的事件 protectedoverridevoidOnPreRender(EventArgse) { //分页样式表信息 if(!thisCustomPagerIsCustomStyle) { thisAddStyleFile(); } baseOnPreRender(e); } //重写服务器控件输出内容的方法 protectedoverridevoidRenderContents(HtmlTextWriteroutput) { //if(DesignMode) //{return;} //写入分页信息 thisCSgetPagerHtml(thisCustomPageriRecordCountthisCustomPageriRowsCountoutput); PageVerifyRenderingInServerForm(this); } /**////<summary> ///控件加载事件 ///</summary> ///<paramname=e></param> protectedoverridevoidOnLoad(EventArgse) { queryString=PageRequestServerVariables[Query_String]; currentUrl=PageRequestPath; inti=; if(thisCustomPagerUrlPaging==true&&!DesignMode) { if(!PageIsPostBack) { intindex; intTryParse(PageRequestQueryString[thisCustomPagerUrlPageIndexName]outindex); if(index<=) index=; if(index>thispageCount) {index=;} PageChangingEventArgsargs=newPageChangingEventArgs(index); OnPageChanging(args); } } if(!DesignMode) { inputPageIndex=PageRequestForm[UniqueID+_input]; intTryParse(inputPageIndexouti); if(i<||i>thispageCount) {i=;} inputPageIndex=iToString(); } baseOnLoad(e); } 上面几个方法是控件固有的所有的控件都会经历这样的生命周期这个过程相对来说是稳定的但是它的内部实现却是不固定而是可变的这也是我们能写出功能不同的控件的原因 为了说明方便先帖个建造者模式的类图: 程序员就相当于建造模式类图当中的Director他的意图决定了自定义控件如何实现例如我想做一个自定义的分面导航控件Control类相当于Builder它负责指引具体的生产者类(ConcreteBuilder)如果完成Director的意图具体的生产者当然就ConcreteBuilder了它按照Control类的指示来完成控件具体的创建过程 这样的程序在建造者模式中并不是标准的它省略了抽象建造者角色及Director类 看来有时候你不想用模式都难使用模式应该是一种顺其自然的现象设计模式它是用来解决问题的并不是让我们强行用它(强扭的瓜不甜)否则会因为过度的设计给原本简单的系统带来维护上的困难 上面的分页控件代码中可以看出所谓建造者模式它内容结构比较复杂往往会包含非常多的方法等但从整体上来说创建过程相对稳定但是它的内部成员不稳定每个控件都具备相同的生命同期从初始化到呈现到最后的销毁但其中的实现过程又是不同的 针对这种情况就可以把相对复杂的创建过程抽象出来让创建过程与实现过程分离从而达到相同的创建过程可以实现 不同的表现方式的目的 创建者模式的特点: :最终创建的产品(Product)内部结构相对复杂 :Product的创建过程稳定 :Product的内部对象的实现过程是可变动的 :Product并不关心内部子系统如何实现(只求结果不关心过程) :Product的创建过程与实现部分分离 :同样的创建过程可以实现不同的表现结果 适用性 没有唯一的标准如果开发者感觉自己的项目适合创建者模式的特点那么你就可以尝试去用否则还是少用 总结: 设计模式离我们并不远其实就在我们身边就看你有没有心去关注它的存在了 一个善于应用OO的程序员总会有机会把设计模式当成解决问题最好的武器 |
