摘要： 最近在整理以前所看文章内容时，发现了几篇2003年程序员合订本里关于 ACE的文章，当年这几篇文章中所谈到的内容就让人非常兴奋，因为在那个国内热火朝天学习设计模式的几年里，这几篇文章因为其内容涉及到了bridge, strategy, adapter, facade等模式在这个网络通信框架中实打实的应用，让我切身体会到了面向对象设计模式的强大火力。同时因为这几篇文章绝不是我们在学习模式应用时想当然的东西，决不是简单的几句玩笑或不成熟的例子所能同日而语。所以我感觉还是把这几篇文章中的核心内容保存到网上比较好。 阅读全文

摘要： 在开始今天的正文之前，首先举两个例子，一个是古代的，一个是当下的。 例子1：(注：本例来自n年前博客园里一位仁兄的忽发奇想，本人觉得有一定道理，这里不妨引用一下） 话说“乾隆”准备派钦差大臣去出使“葛尔丹”，来安抚那里的“臣民部落”。而这个钦差大臣有两件事要做：一是给那些部落金银珠宝，二是赏赐美女。而皇帝身边有两个大臣，分别是“何坤”和“纪晓岚”。这两位大臣的做事风格相信大家早有耳闻，而乾隆也知道如果派何坤去，肯定是把金银珠宝他自已都贪了，美女他自己也会像韦小宝一样照单全收，而结果可能是逼反了葛尔丹。而纪晓岚应该会按乾隆的意思把事件办了。在这个例子中，乾隆这个king就是一个总导演，他决定这个“钦差大臣”由谁来担当，而这个决定取决于其自己的政治意图（即是想安抚还是逼反“葛尔丹”）。 阅读全文

摘要： 声明：本文内容纯属个人观点，官方保留最终解释 通过前几个月的“外围清剿”，我介绍了一些在项目中边边角角的类和项目。当然这种介绍只是前期热身准备。因为从这篇文章开始，本人将跟大家聊一聊关于这个产品架构上面的东西，以备大家对这个产品有一个总体上的认识，从而为后面的文章做一下铺垫。费话少说，开始正文吧:) 首先请大家看一下官方提供的“前台页面层次图”如下： http://nt.discuz.net/doc/Default.aspx?cid=4 阅读全文

摘要： 作为产品中的一大特色，模板机制一经推出，就引来了大家特别是站长们的关注。但它所饱受的风风雨雨也成了那时不少人关注的话题。而今天本人将结合在产品组中的开发经历，介绍一下模板机制在设计使用时的一些体会心得。希望借此陋文，使模板机制揭开“神秘”面纱，为大家在实际设计中提供一些有价值的参考和建议。 好了，开始今天的话题:) 阅读全文

摘要： ICONIX过程的规模大概在重量级Rational Unified Process (RUP)和轻量纺的极限编程之间(XP)。同时这种方法也是用例驱动，但不需要RUP使用记录延续到表中带来的大量开销。和XP一样，它相对较小，不像XP那样摒弃了分析和设计过程。因此，有助于使用UML，同时对需求进行跟踪。该过程遵循Ivar Jacobson的用例驱动思想，能够获得有形，具体，易于理解的用例，开发小组可以使用这个用例来驱动开发工作。 该方法是迭代，循序渐进同时足够的轻量级。因为它遵循20%原则，即用UML中20%的图表来完成设计中80%的需求。从这个角度讲倒是满符合中国国情的，因为具我观察不少国内软件公司都不是肯花心思和时间在设计架构上。 阅读全文

摘要： 在7月份中我曾经写过一篇文章，叫".NET2.0 框架中的 AbstractFactory 模式 " 链接如下：http://www.cnblogs.com/daizhj/archive/2007/07/23/828249.html 里面主要说了在2.0框架下的数据库链接工厂中新增的几个类，而这几个类采用的就是 抽象类工厂模式 （Abstract Factory）。因为在Discuz!NT 2。0中使用了这些新的类，所以导致我们的产品dbhelper.cs可以支持几种数据库（目前官方实现的有sqlserver ,access ,mysql）。但同时因为1。0框架下没有这些类，所以我们采用自已简单实现其中主要的类代码来解决这个问题。这就有了今天文章的内容！ 阅读全文

摘要： 设计前提：早在RC1之前聚合功能还比较弱化时，系统结构比较简单，只用了一个website页面就聚集了大部分的功能调用。因为快速完成之后陆续又加入了不少新特性，导致类的名称(website) 与所聚合提供的功能已完全不相符 (代码已过度膨胀) ，所以重构的任务已变得非常紧迫了。但用什么方式，因为系统聚合时是按内容类型聚合功能页面并决定显示方式的。而这里的内容类型在大概可分为（论坛主题，相册，图片，空间文章（及最新回复）等）。为了尽量简化系统设计时的复杂度，这里只按内容所属的大类（论坛，空间，相册, 图片）来进行简单的初步规划，这就产生出来上面图片所说的类AggregationData,SpaceAggregationData, AlbumAggregationData.cs,ForumAggregationData.cs ...... 阅读全文

摘要： 大约还是去年12月份，当时项目中遇到了一个很棘手的问题，就是管理员（或站长）在后台设置了邮箱信息之后，使用注册邮件发送激活验证码时，总有用户反映不能收到激活信息的邮件。 虽然不能收到邮件的情况有很多，甚至我已通过这个邮件发送程序测试过国内大多数知名网站的邮箱（如126，sina ,sohu ,gmail等），但还是有站长或用户隔三差五反映这个问题。甚至到今天我偶尔还会得到技术支持部门有关这方面问题的报怨。因此，今天这篇文章虽然说到了一个有关这个问题的解决方案（但不完善），但还是希望园子里以前处理过这方面问题或有成功经验的朋友指点一二。 好了，不费话了，开始今天的话题。 阅读全文

摘要： 作为一个社区类型软件，大并发支持和高效稳定运行永远是“硬道理”，而有效安全的使用缓存恰恰能起到事倍功半的效果。而.NET本身所提供的缓存机制又显得过于“单薄”，比如说订制不太灵活方便, 缓存对象之间层次感不强, 使用时缺乏统一的管理等等。 Discuz!NT缓存产生背景： 在去年五月份我加入Discuz!NT项目组时，发现这个项目当时还未使用缓存机制。主要原因是项目还处于起步阶段，很多东西还只是有想法，但未付诸实施，或还没找到合适的方案， 而缓存就是其中一个到底该不该使用，如果使用的该到底能多大程度缓解数据库压力以及开发成本的东西。 阅读全文

摘要： 应用场景：net 框架下的HttpModule (.net2.0 代码) 先看一下 Observer 模式结构图: 阅读全文

摘要： 应用场景：net 框架下的TextWriter，HtmlTextWriter，CssTextWriter,IndentedTextWriter 等 先看一下Decorator 模式结构图: 阅读全文

摘要： 由于最近有了宝宝，导致夜里写文章的时间越来越短，而白天又忙于开发。没办法，只有挤时间去写东西了。 前些天在园子里看到了这篇文章，http://www.cnblogs.com/Yahong111/archive/2007/07/18/822946.html， 对里面写的内容浏览了一下，这里首先对作者的实践精神表示赞赏。我这里只是从别的角度阐述一下AbstractFactory 在这种应用场景下的发展，内容不多，希望大家见谅。 阅读全文

摘要： 摘要：通过重构实现、趋向和去除模式，这是我从Kerievsky那本叫Refactoring to Patterns的书中看到的。 而今天文章的内容是一种对其思想的实践案例。有趣的是在这篇文章中所说到的代码开发和重构过程发生在 2006年7月份， 而我看到的这本书的相关内容只是两天前的事。我在这里不是想说自已的思想与作者已经走 到了一起，而是想说作者的思想也是从实践中来的，而我们的编程也是一种实践，这必然会有相交的可能。 这也是为什么实践类的文章会如此受欢迎的原因。 阅读全文

摘要：第三重: [无模式] 这里我说的无模式，不是当“压根就没有模式”讲。相反，这是一个无穷量，就像我们在大 学时使用的Limit 极限一样。这一层面上永远没有终点，一切只是像坐标轴一样，只有原点，没 有终点。另外，当年张三丰教张无忌太极拳时对张无忌说的，什么时候全忘了，什么时候就全会 了。因为只有满足了应用需求的软件才是好软件，而使用什么设计模式，那是只有程序员才关心 的事。 当你在设计中遇到了问题，在多年经验的基础上，写出了高度可扩展，灵活，效率高，BUG 极少的软件时，而此时设计模式只是被无形中应用于开发过程里。这时你会不知不觉就使用了设 计模式中的思想和好处，而这一切只是基于你的开发习惯，也许只有到这一步才是真正的“融会 贯通”了。 阅读全文

摘要：第二重: [模式合成] 在学习并使用了一段时间的设计模式后（大约四个月到半年），发现设计模式在代码形式上 的一些近似完全可以成为整合一种或两种以上设计模式的桥梁 [当然也要参见和在上面说的那种 模式之间关联图上的说明]。这时在使用设计模式上就要有一定的突破了， 既不能死守代码解释 固步自封，也是能过于激近，甚至把某种设计模式上的优势人为去掉而让自己的代码取而代之， 这都会让自己最后设计的的东西不令人满意[特别是你自己]。那么什么时候才能确定要采用模式 合成呢，我这里给出两个建议，这也是我在去年做一个计费系统时所采用的： 阅读全文

摘要：第一重：[模式 呀 魔式] 本人在刚开始学习设计模式时只看了几个，包括:Strategy,Composite,Singleton，Factory 这四个模式，从一开始感觉的头大到后果看到了这几种模式给程序设计和修改以及调试所带来的 便利好处，让我对那四位大仙真是伸大指佩服。再以后就是又看了其余的一些模式，但越研究越 发现，这些模式就像是一堆同父异母的孩子，有些地方长得很相以，如果不是很了解这一家人， 有时很容易就会张冠李戴了，举个例子：Abstract Factory,bridge,Strategy这三个就有点相似， 如果大家不相信，可以看一下相关的图文说明[特别是图的右半部分]。我想这也是在这一时期大 家有时感到迷糊的原因之一，到底该如果去分清呢？在一些偶然的机会下，我去下载一份 RedSword软件工作室的设计模式迷你手册[因为本人的模式资料只是从网上获取]，最开始的一个 图表引起了我很大的兴趣，图如下： 阅读全文