<?xml version="1.0" encoding="gb2312"?>
<rss version="2.0">
<channel>
<title>设计模式</title>
<link>http://www.kuqin.com/design-patterns/</link>
<description>挖经验 / 设计模式</description>
<language>zh-cn</language>
<generator>Copyright &amp;copy; 2007-2008 &lt;A href=&quot;http://www.kuqin.com&quot;&gt;酷勤网&lt;/A&gt; All Rights Reserved
&lt;A href=&quot;http://www.miibeian.gov.cn/&quot; target=&quot;_blank&quot;&gt;京ICP备07011765号&lt;/A&gt;</generator>
<webmaster>kuqin.com@163.com</webmaster>
<item>
    <title>面向对象的设计模型，数学模型，物理模型</title>
    <link>http://www.kuqin.com/design-patterns/20090620/57850.html</link>
    <description>第一次看到面向对象这个概念是在一本C++的书里面。里面举了个动物的例子。讲禽类，哺乳类，昆虫等等动物的继承关系，多态，等等概念。想起大学时候读的C语言里面的一张程序逻辑图。感觉这个面向对象实在是太神奇了。再后来接触到.net 。开始基于.net平台，用C#语言编写</description>
    <pubDate>2009-06-20</pubDate>
    <category>设计模式</category>
    <author>发条橙子</author>
    <comments>博客园</comments>
</item>
<item>
    <title>设计模式思想换位之另类的观察者</title>
    <link>http://www.kuqin.com/design-patterns/20090327/42968.html</link>
    <description> 松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低。所以我们为了交互对象之间的松耦合设计而在努力。</description>
    <pubDate>2009-03-27</pubDate>
    <category>设计模式</category>
    <author>maddish</author>
    <comments>IT168</comments>
</item>
<item>
    <title>深入浅出单实例Singleton设计模式</title>
    <link>http://www.kuqin.com/design-patterns/20090327/42844.html</link>
    <description>单实例Singleton设计模式可能是被讨论和使用的最广泛的一个设计模式了，这可能也是面试中问得最多的一个设计模式了。这个设计模式主要目的是想在整个系统中只能出现一个类的实例。</description>
    <pubDate>2009-03-27</pubDate>
    <category>设计模式</category>
    <author>陈皓</author>
    <comments>酷壳</comments>
</item>
<item>
    <title>大话“基于对象”与“面向对象”</title>
    <link>http://www.kuqin.com/design-patterns/20090308/38682.html</link>
    <description>面向对象设计是针对面向过程设计，而发展起来的一种先进的编程思想。面向对象是将什么东西都看做对象，它们即相关又独立。这是与面向过程的重大区别之一！面向过程只相关不独立。由于不独立，人们只能按照一定的逻辑顺序来做程序。</description>
    <pubDate>2009-03-08</pubDate>
    <category>设计模式</category>
    <author>hxmhj</author>
    <comments>博客园</comments>
</item>
<item>
    <title>冒号课堂§6.3：前台语言</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36284.html</link>
    <description>前台编程涉及面专，更关注界面设计；后台编程涉及面广，更关注业务逻辑；底层编程涉及面深，更关注系统资源。它们只是侧重点有所不同，并无真正的难易之别、高下之分。 </description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§6.2：平台语言</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36283.html</link>
    <description>作为平台语言，Java和C#均有极为丰富的资源和极强的整合能力，背后又有大公司不遗余力的支持和推广，理所当然地成为大型企业应用的主流选择。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§6.1：系统语言</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36282.html</link>
    <description>在程序性能与生产效率之间，系统语言更看重前者，它们在赋予程序员更多的权利的同时，也带给程序员更多的负担。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§5.4：语言误区</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36281.html</link>
    <description>冒号祭起辩证法：“从另一个角度看，发明一种语言也是对先前语言的一种最高的赞美。C++之于C，Java之于C++，C#之于Java，都是后者对前者的一种承认，哪怕是极不情愿的承认。批判与赞美，继承与发展，谓之扬弃。”</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§5.3：动态语言</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36280.html</link>
    <description>动态语言秉承的一个理念是：优化人的时间而不是机器的时间。为提高人的生产率，宁肯牺牲部分的程序性能或者购买更高配置的硬件。由于硬件相对于人件一直在贬值，该理念便有了合理的现实基础。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§5.2：数据类型</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36279.html</link>
    <description>冒号说道：“数据类型包含两个要素：一个是允许取值的集合，一个是允许参与的运算。例如int类型在Java中既定义了介于&amp;#8722; 231 和231 &amp;#8722; 1之间的整数集合，也定义了该集合上的整数所能进行的运算。现在的问题是：数据类型的意义何在？”</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§5.1：教学计划</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36278.html</link>
    <description>所谓迭代学习法，是指在具体知识与抽象理论之间进行增量式的循环学习。一个合格的程序员不应只局限某一层的应用开发。要想工作胜任愉快，才能、兴趣、方法和努力缺一不可。一套好的方法可以激发才能、兴趣和努力。 </description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§4.4：情景范式</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36277.html</link>
    <description>Jess、Drools、JLisa、JRules等规则引擎主要基于正向推理，能无缝地与Java平台集成。它们提供了逻辑式编程环境，能有效地将业务规则从应用程序中分离出来，提高了软件的灵活性和可维护性。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§4.3：汇总范式</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36276.html</link>
    <description>相比设计模式，编程范式针对的问题领域更广泛，提出的思想和方法更普适、更抽象、更系统。此外，设计模式重在设计，对语言和工具的要求不高，而编程范式需要建立一套抽象机制和方法体系，离不开语言或工具的支持。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§4.2：逻辑范式</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36275.html</link>
    <description>相对于命令式，逻辑式更简洁、更抽象、更少副作用，能提高生产效率，还能用于快速原型开发。但在运行效率、可掌控性、语言成熟度等方面有所欠缺。另外，因其思维方式独特而鲜为人用，适合基于规则而非基于状态的应用 。 </description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§4.1：函数范式</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36274.html</link>
    <description>事件驱动式（Event-Driven）可以是一种编程范式，可以是一种架构模型，也可以是一种设计模式。总之，每种范式都代表着一套独特而有效的解决问题的思想和方法。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§3.4：事件驱动</title>
    <link>http://www.kuqin.com/design-patterns/20090224/36273.html</link>
    <description>基于事件驱动的系统一般提供两类的内建事件：一类是底层事件或称原生事件，在用户图形界面（GUI）系统中这类事件直接由鼠标、键盘等硬件设备触发；一类是语义事件，一般代表用户的行为逻辑，是若干底层事件的组合。</description>
    <pubDate>2009-02-24</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>重构并非设计的替代品</title>
    <link>http://www.kuqin.com/design-patterns/20090214/34901.html</link>
    <description>预先做大量的设计本身不是设计，它只是实现设计的一种方式。而敏捷实践者更倾向于另外一种方式，即当前的设计来自于实际要做的功能。设计是对系统需求的反应和适应，而系统需求本身会随着客户的需要在不断地发展和变化。</description>
    <pubDate>2009-02-14</pubDate>
    <category>设计模式</category>
    <author>Chris Sims译者 张晓庆</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>关于面向对象的一点思考</title>
    <link>http://www.kuqin.com/design-patterns/20081229/32186.html</link>
    <description>面向对象开发技术带来很多好处，比如系统可理解性好、可维护性高、可重用性和可扩展性高等。但是纯粹的面向对象，前期开发成本是很高的，有更高的设计要求，需要更好地进行面向对象思考和分析；同时，按照目前的开发技术来看，有时候不能完全解决系统的性能“瓶颈”。</description>
    <pubDate>2008-12-29</pubDate>
    <category>设计模式</category>
    <author>sunp</author>
    <comments>阿里巴巴（软件）开发者博客</comments>
</item>
<item>
    <title>Paulo Merson谈基于UML 2.0的应用架构编档</title>
    <link>http://www.kuqin.com/design-patterns/20081218/31148.html</link>
    <description>UML规范有一个针对Java EE的概要文件、一个针对.Net的概要文件，还有其它的一些，这些都作为UML规范的附件而存在。重用或创建自己的衍型和概要文件是个很不错的主意。</description>
    <pubDate>2008-12-18</pubDate>
    <category>设计模式</category>
    <author>Srini Penchikala译者 王丽娟</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>OOP更适合组织你的代码么？</title>
    <link>http://www.kuqin.com/design-patterns/20081212/30498.html</link>
    <description>Tang认为“如果语言不对约定进行强制限定，人们就不会遵守它”。他在尝试了为模块的排列定义一些模式后断言“这是特定领域所固有的问题：没有哪一个恰当的组织原则可以适合于所有人的程序”。</description>
    <pubDate>2008-12-12</pubDate>
    <category>设计模式</category>
    <author>Sadek Drobi译者 张龙</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>编码的邪恶：复制与粘帖</title>
    <link>http://www.kuqin.com/design-patterns/20081124/28386.html</link>
    <description>复制和粘帖是一种非常邪恶的编码方式。在编码时，需要千方百计的去想办法减少复制和粘帖。这是在编码时就应该注意的问题，而不是放在重构阶段去做的事情。至于使用什么方法，使用什么手段，使用什么模式则是细节问题。</description>
    <pubDate>2008-11-24</pubDate>
    <category>设计模式</category>
    <author>xiaotie</author>
    <comments>博客园</comments>
</item>
<item>
    <title>滥用的单例模式有多少害处</title>
    <link>http://www.kuqin.com/design-patterns/20081119/27733.html</link>
    <description>最近在一个C++的新项目中，发现了非常多的地方用了单例模式，几乎到了滥用的地步，带来的不好的地方也显现了出来。本文总结一下单例模式的害处，与大家分享，也提醒一些初学设计模式的朋友：设计模式有限制，用错了场景依然不是好的设计。</description>
    <pubDate>2008-11-19</pubDate>
    <category>设计模式</category>
    <author>苏林</author>
    <comments>csdn博客</comments>
</item>
<item>
    <title>解耦的故事：权限设计2</title>
    <link>http://www.kuqin.com/design-patterns/20081117/27502.html</link>
    <description>权限与业务不要耦合，因为两者实际上关系不大，有无权限，并不会决定这个程序的执行过程。一直以权限设计作为解耦的故事主题，但是最重要的还是一个设计思想，不单是权限的问题。</description>
    <pubDate>2008-11-17</pubDate>
    <category>设计模式</category>
    <author>Kevin Zou</author>
    <comments>博客园</comments>
</item>
<item>
    <title>冒号课堂§3.3：切面范式</title>
    <link>http://www.kuqin.com/design-patterns/20081117/27500.html</link>
    <description>句号积极发言：“从中看出，AOP的实施分三步：切面分解、切面实现和切面合成。其中第一步是在设计者的头脑中进行的，第三步是通过AOP的工具实现的，真正需要程序员编码的部分在第二步，即分别实现各切面的advice。”</description>
    <pubDate>2008-11-17</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§3.2：超级范式</title>
    <link>http://www.kuqin.com/design-patterns/20081117/27498.html</link>
    <description>语言导向式编程一般通过元编程将专用语言转化为通用语言；产生式编程与静态元编程都能自动生成源代码。产生式编程强调代码的生成，元编程强调生成代码的可执行性。此外，动态元编程并不生成源代码，但能在运行期间修改程序。</description>
    <pubDate>2008-11-17</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>建模语言应该是什么样子？UML又处于何种位置？</title>
    <link>http://www.kuqin.com/design-patterns/20081114/26984.html</link>
    <description>UML并不是适用于模型驱动开发的工具。UML不能被编译、执行或解释，那它就“只剩文档编制的作用”，而且“对项目来说，除了作为详尽的代码注释外别无他用”。</description>
    <pubDate>2008-11-14</pubDate>
    <category>设计模式</category>
    <author>Sadek Drobi译者 王丽娟</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>微软的模型驱动开发战略</title>
    <link>http://www.kuqin.com/design-patterns/20081112/26659.html</link>
    <description>随着OSLO不断成熟，微软开始改变建模方式的发展路线。经过数年专注于领域特定语言（DSLs）相关建模工具的研究，微软扩宽了他们的产品策略，包含了更多UML相关建模工具。</description>
    <pubDate>2008-11-12</pubDate>
    <category>设计模式</category>
    <author>Boris Lublinsky 译者：王速瑜</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>冒号课堂§3.1：泛型范式</title>
    <link>http://www.kuqin.com/design-patterns/20081109/26405.html</link>
    <description>泛型编程能打破静态类型语言的数据类型之间的壁垒，在不牺牲效率并确保类型安全的情况下，最大限度地提高算法的普适性。泛型编程不仅能泛化算法中涉及的概念（数据类型），还能泛化行为（函数、方法、运算）。 </description>
    <pubDate>2008-11-09</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§2.4：并发范式</title>
    <link>http://www.kuqin.com/design-patterns/20081109/26404.html</link>
    <description>并发式编程以进程为导向、以任务为中心、以资源共享与竞争为主线。并发式编程有助于提高运行效率、充分利用资源、提高软件的响应能力、改善用户体验，同时以进程为单位将系统模块化，更加真实地模拟现实世界。</description>
    <pubDate>2008-11-09</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§2.3：对象范式</title>
    <link>http://www.kuqin.com/design-patterns/20081109/26403.html</link>
    <description>OOP的核心思想可以归纳为：以数据为中心组织逻辑，将系统视为相互作用的对象集合，并利用继承与多态来增强重用性。OOP既不能脱离其他范式，也绝非适用于一切应用。可重用性、可扩展性和灵活性是所有范式和语言的共同目标，并非OOP所独有。</description>
    <pubDate>2008-11-09</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§2.2：声明范式</title>
    <link>http://www.kuqin.com/design-patterns/20081109/26402.html</link>
    <description>声明式编程专注问题的分析和表达而不是算法实现，不用指明执行顺序，一般没有或极少副作用，也不存在内存管理问题。这些都大大降低了编程的复杂度，同时也非常适合于并发式计算。</description>
    <pubDate>2008-11-09</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§2.1：命令范式</title>
    <link>http://www.kuqin.com/design-patterns/20081109/26401.html</link>
    <description>命令式编程模拟电脑运算，是行动导向的，关键在于定义解法，即“怎么做”，因而算法是显性而目标是隐性的；声明式编程模拟人脑思维，是目标驱动的，关键在于描述问题，即“做什么”，因而目标是显性而算法是隐性的。</description>
    <pubDate>2008-11-09</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>冒号课堂§1.0：开班导言</title>
    <link>http://www.kuqin.com/design-patterns/20081109/26400.html</link>
    <description>编程范式是计算机编程中的基本风格和典范模式，是编程者在其所创造的虚拟世界中自觉不自觉采用的世界观和方法论。每种范式都引导人们带着其特有的倾向和思路去分析和解决问题。OOP就是一种编程范式。 </description>
    <pubDate>2008-11-09</pubDate>
    <category>设计模式</category>
    <author>郑晖</author>
    <comments>BlogJava</comments>
</item>
<item>
    <title>揭示常见的重构误区</title>
    <link>http://www.kuqin.com/design-patterns/20081107/25991.html</link>
    <description>对，重构从一诞生之初，就从未放言像面向对象或面向方面编程那般会成为一种划时代的全新模式。它仅仅是从根本上改变你编码的方式：它定义了一些规则，使得利用工具（例如点击按钮）完成代码的复杂转换成为可能。</description>
    <pubDate>2008-11-07</pubDate>
    <category>设计模式</category>
    <author>Danijel Arsenovski译者 张逸</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>正确认识使用UML中的类图——辨析类图的两种存在形式 </title>
    <link>http://www.kuqin.com/design-patterns/20081028/24802.html</link>
    <description>1.软件分析与设计是编码前的两个阶段，其中分析仅与业务有关，而与技术无关；2.分析阶段由分析师绘制领域类图，设计阶段由设计师绘制实现类图；3.领域类图表示系统的静态领域结构，其中的类不与最终程序中的类对应；设计类图表示系统的技术架构……</description>
    <pubDate>2008-10-28</pubDate>
    <category>设计模式</category>
    <author>T2噬菌体</author>
    <comments>博客园</comments>
</item>
<item>
    <title>从“UML何时死掉”谈起</title>
    <link>http://www.kuqin.com/design-patterns/20081024/24209.html</link>
    <description>Ivar把UML之死，归于一种抽象的失败，或其被更高的抽象所替代。实在是无比正确的，因为UML也是建立在结构化、抽象这样一些基元的理论之上。</description>
    <pubDate>2008-10-24</pubDate>
    <category>设计模式</category>
    <author>blog.csdn.net</author>
    <comments>IT168</comments>
</item>
<item>
    <title>巧用需求、设计文档里的图</title>
    <link>http://www.kuqin.com/design-patterns/20081019/23309.html</link>
    <description>状态图描述了一个任务可能的状态，以及各个状态间的关联关系（每个状态应该是平级的），状态图在辅助研发人员检查程序完整性的同时，也为交互设计人员任务状态提供有效的提示。</description>
    <pubDate>2008-10-19</pubDate>
    <category>设计模式</category>
    <author>不言堂</author>
    <comments>博客大巴</comments>
</item>
<item>
    <title>画好Web流程图</title>
    <link>http://www.kuqin.com/design-patterns/20081015/22722.html</link>
    <description>除了确保别人能看懂你的流程图，评价流程图的好坏，还要谨记“流程图是要指导UI设计的，是UI设计的参照物”，必须“覆盖了各种可能的情况和细节”，“考虑到系统的设计和承受能力”。</description>
    <pubDate>2008-10-15</pubDate>
    <category>设计模式</category>
    <author>郭晓刚</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>OO和面向过程的SQL </title>
    <link>http://www.kuqin.com/design-patterns/20081011/22091.html</link>
    <description>在以数据库为主体，且包含了许多计算复杂度高功能的信息管理项目上，该领域对应的是一个面向关系的世界，表和表间的关系就是直接的、稳定的业务关系，在这种项目中使用多余的对象映射就会导致实现复杂度提高，OO的劣势大于其优势。</description>
    <pubDate>2008-10-11</pubDate>
    <category>设计模式</category>
    <author>JustForKim</author>
    <comments>博客园</comments>
</item>
<item>
    <title>对话软件大师Martin Fowler：测试驱动开发</title>
    <link>http://www.kuqin.com/design-patterns/20081007/21233.html</link>
    <description>Martin Fowler：我之所以采用逐步设计以及先写测试的方法，是因为这样做使我有了一个简明扼要的任务列表。在每个阶段的结尾，我都有一些已经做完的事情。于是我对自己说，好吧，这些东西是完成了的，把它们添加到已有的代码中吧。</description>
    <pubDate>2008-10-07</pubDate>
    <category>设计模式</category>
    <author>Bill Venners</author>
    <comments>译言</comments>
</item>
<item>
    <title>对话软件大师Martin Fowler：灵活性与复杂性</title>
    <link>http://www.kuqin.com/design-patterns/20081007/21232.html</link>
    <description>Martin Fowler：灵活性的代价就是复杂性。每次当你往代码中加入一些额外的东西以提高灵活性时，通常也使你的代码变得更加复杂。假如你的预期是对的，未来确实需要这种灵活性，那么你的超前工作得到了回报。</description>
    <pubDate>2008-10-07</pubDate>
    <category>设计模式</category>
    <author>Bill Venners</author>
    <comments>译言</comments>
</item>
<item>
    <title>对话软件大师Martin Fowler：进化型设计</title>
    <link>http://www.kuqin.com/design-patterns/20080928/20329.html</link>
    <description>Martin Fowler:我认为一些地方还是可以用到预先设计的，不过不会很多。一些人——像肯特·贝克和罗恩·杰弗里斯——认为预先设计已 经消亡了。从某种意义上来说，他们是对的，因为你可以借助进化型设计搭建更复杂的系统。</description>
    <pubDate>2008-09-28</pubDate>
    <category>设计模式</category>
    <author>Bill Venners</author>
    <comments>译言</comments>
</item>
<item>
    <title>对话软件大师Martin Fowler：设计原则与代码所有权</title>
    <link>http://www.kuqin.com/design-patterns/20080928/20328.html</link>
    <description>Martin Fowler:我把代码所有权分为三类。在极限编程中用到的代码所有权有时称为集体代码所有权，有时也可以说“无代码所有权”。在这种所有权中，团队中任何人都不具有对代码的所有权。也就是说，任何成员可以在任意时间内改动系统中的任何代码。</description>
    <pubDate>2008-09-28</pubDate>
    <category>设计模式</category>
    <author>Bill Venners</author>
    <comments>译言</comments>
</item>
<item>
    <title>对话软件大师Martin Fowler：重构</title>
    <link>http://www.kuqin.com/design-patterns/20080928/20327.html</link>
    <description>Martin Fowler:重构并非让你变态地去重命名一大堆东西，而理由仅仅是你觉得那样好。重构必须要有收益。假设你在做重命名，那么你应 该查找那些名字和意义不符的方法，并且其他使用该方法的人也觉得应该改名才行。</description>
    <pubDate>2008-09-28</pubDate>
    <category>设计模式</category>
    <author>Bill Venners</author>
    <comments>译言</comments>
</item>
<item>
    <title>从面向对象设计谈接口和抽象类的异同</title>
    <link>http://www.kuqin.com/design-patterns/20080926/20036.html</link>
    <description>一个类可以实现多个接口，接口是没有实际意义的，所以即使一个类实现了再多接口，它还可以不违反类的单一职责原则。反之，继承于多个抽象类，大多会违反类的单一职责原则，要不然就是那几个抽象类设计的不合理。</description>
    <pubDate>2008-09-26</pubDate>
    <category>设计模式</category>
    <author>浪迹福州</author>
    <comments>博客园</comments>
</item>
<item>
    <title>微软加入OMG：选择DSL还是UML？</title>
    <link>http://www.kuqin.com/design-patterns/20080922/19392.html</link>
    <description>Jacky总结说：实际上，GPL和DSL的区分并不是非黑即白。换句话说，从通用语言到领域特定语言的过渡并不是一个阶跃函数。通常，通过使用扩展机制（比如UML中的stereotypes），GPL在某种程度上可被加以定制，以提高模型所表达的目标领域中信息的精确性。</description>
    <pubDate>2008-09-22</pubDate>
    <category>设计模式</category>
    <author>Jean-Jacques Dubray译者 霍泰稳</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>面向对象与形而上学</title>
    <link>http://www.kuqin.com/design-patterns/20080920/18948.html</link>
    <description>正如人类由简单思维而至逻辑性的思维，再到可以改天化物究天地易理的辩证理论一样，编程中的形而上学终会被辩证而智能的辩证所替代，到那时或许语言也没有二义性了，它自己就会辩证了。</description>
    <pubDate>2008-09-20</pubDate>
    <category>设计模式</category>
    <author>重典</author>
    <comments>博客园</comments>
</item>
<item>
    <title>并行思维 [III] </title>
    <link>http://www.kuqin.com/design-patterns/20080902/16264.html</link>
    <description>当编写的代码在并行/并发运行时会引发问题，那就不能说是线程安全的。单线程程序仅包含一个控制流，所以也就无所谓线程安全。但在多线程程序中，同一个函数和资源或许被多个控制流并发使用。因此，为多线程编写的代码必须要线程安全。</description>
    <pubDate>2008-09-02</pubDate>
    <category>设计模式</category>
    <author>Angel Lucifer</author>
    <comments>博客园</comments>
</item>
<item>
    <title>从设计原则谈软件开发（一）</title>
    <link>http://www.kuqin.com/design-patterns/20080827/15284.html</link>
    <description>我之前写过的接口，接口的设计一定要遵循的就是单一职责原则。我之前说，接口不能设计太大，也不能设计太小。我们用这句话再来对单一职责原则做下总结。单一职责，不是说我们把职责分得越细越好。</description>
    <pubDate>2008-08-27</pubDate>
    <category>设计模式</category>
    <author>飞林沙</author>
    <comments>博客园</comments>
</item>
<item>
    <title>并行思维 [II] </title>
    <link>http://www.kuqin.com/design-patterns/20080824/14953.html</link>
    <description>有一个很明显的事实是：最佳串行化算法很少是最佳并行化算法，反之亦然。这意味着要使程序在单核，多核系统上都运行良好，仅仅编写良好的串行代码或并行代码并不够。 超级计算机程序员从实践中得知，并发任务工作量会随着问题规模的功能快速增长。</description>
    <pubDate>2008-08-24</pubDate>
    <category>设计模式</category>
    <author>Angel Lucifer</author>
    <comments>InfoQ</comments>
</item>

</channel>
</rss>
