<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>dongliheng的专栏 - design patterns</title><link>http://blog.csdn.net/dongliheng/category/314657.aspx</link><description>java patterns</description><dc:language>zh-CN</dc:language><lastUpdateTime>Fri, 11 Apr 2008 00:16:04 GMT</lastUpdateTime><ttl>60</ttl><item><dc:creator>dongliheng</dc:creator><title>OO思想</title><link>http://blog.csdn.net/dongliheng/archive/2007/07/08/1683054.aspx</link><pubDate>Sun, 08 Jul 2007 23:00:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/07/08/1683054.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1683054.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/07/08/1683054.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1683054.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1683054</trackback:ping><description>从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子（包括数据表的字段），而不是业务对象。&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1683054.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>实战DDD(Domain-Driven Design领域驱动设计:Evans DDD)</title><link>http://blog.csdn.net/dongliheng/archive/2007/07/04/1678845.aspx</link><pubDate>Wed, 04 Jul 2007 18:47:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/07/04/1678845.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1678845.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/07/04/1678845.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1678845.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1678845</trackback:ping><description>2004年著名建模专家Eric Evans发表了他最具影响力的著名书籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文译名：领域驱动设计　2006年3月清华出版社译本，或称 Domain Driven-Design architecture [Evans DDD]）。模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。单一的领域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1678845.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>面向对象与领域建模</title><link>http://blog.csdn.net/dongliheng/archive/2007/07/04/1678844.aspx</link><pubDate>Wed, 04 Jul 2007 18:46:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/07/04/1678844.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1678844.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/07/04/1678844.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1678844.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1678844</trackback:ping><description>第一阶段：围绕数据库的驱动的分析设计，新软件项目总是从设计数据库及其字段开始。这种围绕数据库分析设计的缺点非常明显：首先，不能迅速有效全面认识反映需求，世界不只是由简单的关系数据组成，而且 使用关系数据来反映现实需求，不符合人类自然思维（OO才是），是一种扭曲的分析方法，特别对于初学者，他们接受数据库分析方法的难度反而可能会大于OO分析方法，现在很多职业学校和社会培训，基础课程从数据库开始，从某种程度上，是历史倒退， 严重阻碍中国软件发展的进程。&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1678844.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>Factory, Abstract Factory, Factory Method, 和Builder模式的思考 </title><link>http://blog.csdn.net/dongliheng/archive/2007/07/02/1674852.aspx</link><pubDate>Mon, 02 Jul 2007 00:54:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/07/02/1674852.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1674852.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/07/02/1674852.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1674852.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1674852</trackback:ping><description>Factory, Abstract Factory, Factory Method, 和Builder模式的思考 &lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1674852.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>7个软件开发原则</title><link>http://blog.csdn.net/dongliheng/archive/2007/07/02/1674837.aspx</link><pubDate>Mon, 02 Jul 2007 00:30:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/07/02/1674837.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1674837.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/07/02/1674837.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1674837.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1674837</trackback:ping><description>软件重复出现至少会导致以下问题： · 其中的一个版本会过期 · 代码的责任会四处散开，导致代码难以理解 · 当你修改代码时，需要重复修改很多地方，一不小心就会遗漏 · 你不能很好地进行性能优化。重复代码需要refactoring是毫无疑问的，关键在于，你如何找到重复代码，如果所有的重复代码都是死板的重复，那问题是很容易解决的。但是软件开发的复杂因素可能往往使重复代码表现为相似性而并非完全的重复。另一个问题就是排除重复代码的粒度，只有大段的重复代码有价值去排除，还是即使是小小的2、3句重复代码就应该去排除。&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1674837.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>你还在用if else吗</title><link>http://blog.csdn.net/dongliheng/archive/2007/07/01/1673064.aspx</link><pubDate>Sun, 01 Jul 2007 02:34:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/07/01/1673064.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1673064.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/07/01/1673064.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1673064.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1673064</trackback:ping><description>思维习惯&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1673064.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>非模式思维的惩罚</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/24/1665013.aspx</link><pubDate>Sun, 24 Jun 2007 23:08:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/24/1665013.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1665013.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/24/1665013.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1665013.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1665013</trackback:ping><description>非模式思维的惩罚面向对象软件体系是和面向过程体系格格不入的，面向对象的各种技术如单元测试　性能缓存等等都是OO体系，如果我们没有具备模式思维来编程，由此而诞生的软件架构必然失败，失败在哪里？有人可能奇怪：非模式思维属于设计问题，怎么会对性能影响，这是将设计和性能对立起来，性能也是一种设计，池模式以及缓存也是属于模式啊，但是缓存的高效率应用是建立良好的对象设计基础上，或者说是良好的领域建模上，否则就是使用缓存，也会导致粒度或动态机制不准确，无法发挥缓存效率，甚至无法使用缓存。&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1665013.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>Java企业系统架构选择考量</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/24/1664746.aspx</link><pubDate>Sun, 24 Jun 2007 17:43:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/24/1664746.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1664746.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/24/1664746.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1664746.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1664746</trackback:ping><description>因为EJB标准的推出，业务组件层以前基本是EJB的天下，但是EJB功能实在太强大，它考虑了世界顶级大型系统需求，因此免不了显得很复杂，当初，基本上所有的大型企业高端都是选用J2EE，选用J2EE实际是选用EJB。POJO组件，POJO这个概念其实当初是针对EJB缺点而推出，EJB要求应用系统的组件必须继承或依赖EJB容器，这样使得调试变的不方便，但是后来，POJO的概念已经不只最初这些概念，POJO代表那种与周围完全脱离关系、自由自在的Object了，如果应用系统的Model或者Service都是POJO，意味着你的应用系统不依赖任何其他系统，解耦性灵活性高。&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1664746.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>Memento备望录模式</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1663006.aspx</link><pubDate>Sat, 23 Jun 2007 09:43:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1663006.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1663006.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1663006.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1663006.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1663006</trackback:ping><description>Memento备望录模式定义:memento是一个保存另外一个对象内部状态拷贝的对象.这样以后就可以将该对象恢复到原先保存的状态.// 创建一个Memento　　public Memento getMemento(){　　　　return new Memento(this);　　}// 恢复到原始值　　public void setMemento(Memento m){　　　　 number = m.number;　　　　 file = m.file;　　}&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1663006.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>Flyweight模式</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662961.aspx</link><pubDate>Sat, 23 Jun 2007 09:28:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662961.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1662961.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662961.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1662961.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1662961</trackback:ping><description>说白点,就是先捏一个的原始模型,然后随着不同场合和环境,再产生各具特征的具体模型,很显然,在这里需要产生不同的新对象,所以Flyweight模式中常出现Factory模式.Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个Flyweight pool(模式池)来存放内部状态的对象.Flyweight flyweight = (Flyweight) flyweights.get(key);if( flyweight == null ) {            //产生新的ConcreteFlyweight　　　　　　flyweight = new ConcreteFlyweight(); 　　　　　　flyweights.put( key, flyweight ); 　　　　}&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1662961.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>适配器模式</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662953.aspx</link><pubDate>Sat, 23 Jun 2007 09:27:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662953.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1662953.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662953.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1662953.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1662953</trackback:ping><description>private RoundPeg roundPeg;public PegAdapter(RoundPeg peg)(this.roundPeg=peg;PegAdapter首先继承SquarePeg，然后使用new的组合生成对象方式，生成RoundPeg的对象roundPeg，再重载父类insert()方法。进一步使用上面的PegAdapter是继承了SquarePeg,如果我们需要两边继承，即继承SquarePeg 又继承RoundPeg,因为Java中不允许多继承，但是我们可以实现(implements)两个接口(interface)// 构造方法　　public PegAdapter(RoundPeg peg){this.roundPeg=peg;}　　// 构造方法　　public PegAdapter(SquarePeg peg)(this.squarePeg=peg;)&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1662953.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>Proxy设计模式,Jive的核心接口</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662947.aspx</link><pubDate>Sat, 23 Jun 2007 09:26:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662947.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1662947.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662947.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1662947.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1662947</trackback:ping><description>Proxy设计模式,Jive的核心接口&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1662947.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>Builder模式</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662929.aspx</link><pubDate>Sat, 23 Jun 2007 09:22:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662929.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1662929.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662929.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1662929.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1662929</trackback:ping><description>Builder模式定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.//创建部件A　　比如创建汽车车轮　　void buildPartA(); 　　//创建部件B 比如创建汽车方向盘　　void buildPartB(); 　　//创建部件C 比如创建汽车发动机　　void buildPartC();&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1662929.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>原型模式</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662924.aspx</link><pubDate>Sat, 23 Jun 2007 09:21:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662924.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1662924.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662924.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1662924.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1662924</trackback:ping><description>原型模式定义:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。如何使用?因为Java中的提供clone()方法来实现对象的克隆,所以Prototype模式实现一下子变得很简单.String spoonName;public void setSpoonName(String spoonName) {this.spoonName = spoonName;&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1662924.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>dongliheng</dc:creator><title>工厂模式</title><link>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662919.aspx</link><pubDate>Sat, 23 Jun 2007 09:20:00 GMT</pubDate><guid>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662919.aspx</guid><wfw:comment>http://blog.csdn.net/dongliheng/comments/1662919.aspx</wfw:comment><comments>http://blog.csdn.net/dongliheng/archive/2007/06/23/1662919.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/dongliheng/comments/commentRss/1662919.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1662919</trackback:ping><description>还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample .我们要实例化他们时,如下:Sample mysample=new MySample();Sample hissample=new HisSample();随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.工厂方法你会建立一个专门生产Sample实例的工厂:&lt;img src ="http://blog.csdn.net/dongliheng/aggbug/1662919.aspx" width = "1" height = "1" /&gt;</description></item></channel></rss>