http://www.kuqin.com/design-patterns/ 挖经验 / 设计模式 zh-cn Copyright &copy; 2007-2008 <A href="http://www.kuqin.com">酷勤网</A> All Rights Reserved <A href="http://www.miibeian.gov.cn/" target="_blank">京ICP备07011765号</A> kuqin.com@163.com http://www.kuqin.com/design-patterns/20080613/9440.html 要解耦﹐首先就要进行抽象﹐权限究竟能不能抽象?我认为通常意义上的权限应该分为2类﹕一类是用户是否有权进行某项动作﹐如管理员可以删贴﹐人事考勤员可以修改考勤数据。另一类我将它称为数据权限﹐如某某人可以查看某某部门的人员信息﹐某某人审核某某厂别的订单等 2008-06-13 设计模式 小生 博客园 http://www.kuqin.com/design-patterns/20080610/9381.html 1. 如果你只对某个蹲位情有独钟，就要WaitOne()，但是不要忘了ReleaseMutex()，千万别WaitOne()两次只ReleaseMutex()一次；2. 如果你喜欢讲排场，需要占2个蹲位才肯办事，则要WaitAll；3. 如果你觉得随便去哪个蹲位办事都无所谓，那就可以WaitAny…… 2008-06-10 设计模式 1-2-3 博客园 http://www.kuqin.com/design-patterns/20080605/9218.html 我可以提供另一种方案来达到同样的效果。我可以让线程1里面的指定代码块不执行完，线程2就一直处于阻塞(ThreadState.WaitSleepJoin)状态。要达到这个效果，需要使用.net里的两个函数。Monitor.Enter(n); Monitor.Exit(n); 2008-06-05 设计模式 1-2-3 博客园 http://www.kuqin.com/design-patterns/20080605/9217.html 只用了40秒钟，这个程序就计算出了把一个初始为0的变量n累加20亿次1，变量n将等于20亿。什么？你说我是白费CPU不干正经事？这有什么，客户喜欢！可是，客户居然嫌它太慢了，并且威胁说如果不能把它压缩到10秒以内就让我去见上帝。 2008-06-05 设计模式 1-2-3 博客园 http://www.kuqin.com/design-patterns/20080602/9177.html Purdy大体上分10个步骤逐步剖析了可伸缩性问题，这10个步骤为：10 理解问题；9 定义需求；8 架构胜于技术；7 - 理解基本要素；6 网络可视化；5 设计可视化；4a 负载计划；4b 分割度量；3a 失败计划；3b - 复制可用性；2 值得实现伸缩性的点；1 - 简化 2008-06-02 设计模式 Scott Delap译者 张龙 InfoQ http://www.kuqin.com/design-patterns/20080531/9120.html 我建议你将开闭原则作为一个设计方向而非一个完全的目标。如果你试图将你能想到所有可能改变的东西都变成完全可嵌入式的，你很有可能创建一个非常难于工作的过度设计的系统。你可能并非总是试图写一些在各个方面都满足开闭原则的代码，但是即使只进行到中途也是非常有益 2008-05-31 设计模式 Jeremy Miller 博客园 http://www.kuqin.com/design-patterns/20080521/8783.html 拷贝粘贴编程，通过拷贝源语句来实现代码复用将导致很严重的维护问题；蘑菇管理，在一些架构和管理周期里，一明显的策略是让系统开发者和系统用户隔离开；失效的代码和遗忘的设计信息封存在一个已经发生变化的设计中。这类似火山中的熔岩流。 2008-05-21 设计模式 不详 JavaEye http://www.kuqin.com/design-patterns/20080514/8468.html 软件开发、设计原则与设计模式的关系，我不恰当的比喻为战争、战略与战术的关系；要取得战争的全面胜利，你首先要在战略上把握好，然后才是战术上指挥好；同样，要开发出好的软件，首先要遵循一定的设计原则，为了达到我们的目的，在开发中就恰当的使用相应的设计模式。 2008-05-14 设计模式 梁-兄 C++博客 http://www.kuqin.com/design-patterns/20080514/8464.html 双向的关联意味着强耦合，是不是这种双向关联在程序设计中是必要的呢?另外假设我要找到老师教授的全部学生是不是需要分两步加载才能得到结果，还是一步就可以了？假设老师的信息和他教授的学生的信息都有了改变，是不是要分别更新还是一条SQL语句就搞定了？ 2008-05-14 设计模式 怪怪 博客园 http://www.kuqin.com/design-patterns/20080514/8459.html 一个“好的设计”是会自动慢慢浮现、完成演化的。换句话说，面对一个被认为是良好的、但是无法演化的设计，我们可以很快提出一个设计，它在本质上与前者类似，但是“更好”而且可以演化。让它“更好”的过程，也从侧面使其更易于演化，而不必直接去解决演化问题。 2008-05-14 设计模式 Amr Elssamadisy译者 郑柯 InfoQ http://www.kuqin.com/design-patterns/20080513/8453.html 用的OO语言干的面向过程的勾当这种事实在是太多太多了。你用了C#但你的程序可能和OCP边都沾不上。很多项目OO语言下其实就是一堆面向过程的程序，当初写代码的人一走，复用，维护，扩展都几乎是不可能的,很多项目的失败就是这个简单的原因。 2008-05-13 设计模式 炭炭 博客园 http://www.kuqin.com/design-patterns/20080513/8452.html 作为开发人员来说不论你用那一种的思想来看待问题和分析问题，你的最终结果就是将你的思维转化为代码，对于初学者来说，跟他们讲用那种方式分析和架构有点偏离他们的实际，他们需要首先学好的是开发上的技巧，能说能做，而不是光说不做。 2008-05-13 设计模式 小余(Yice) 博客园 http://www.kuqin.com/design-patterns/20080511/8344.html 在这里再次强调一下我的体会。目标驱动作为， 问题驱动学习， 这是最好的办法。 第二点就是对好的东西的认知， 第三点是孜孜不倦的改进。 这些东西没达到一定的程度， 学习什么、认可那种， 也会经常走到半路， 就停止了， 然后自以为看到了全部的风景。 2008-05-11 设计模式 怪怪 博客园 http://www.kuqin.com/design-patterns/20080511/8326.html 是否在学习面向对象的语言之前, 一定需要学习面向过程的语言? 我认为, 其实是大可不必的. 我们学习任何一门语言的时候, 都不需要, 也不应该全盘接受语言的设计思想, 甚至将其奉为圭臬, 非此设计思想不可. 一旦程序员能够灵活运用语言特性允许的设计方式, 最初学习的语言 2008-05-11 设计模式 随风流月 博客园 http://www.kuqin.com/design-patterns/20080511/8319.html 所有的初学者们，面向结构的语言并没有过时，如果你们的老师在没有先让你学好面向对象之前就让你上马学习面向对象，那么他就是用一种不负责任的态度进行教学。浮沙之上岂能筑高台。先静下心来，切忌浮躁，一步一个脚印才能走得更远。 2008-05-11 设计模式 小余(Yice) 博客园 http://www.kuqin.com/design-patterns/20080506/8026.html 发现变化隔离封装变化是动因，关闭修改打开扩展是限制；简单工厂很好地遵守了DRY原则，对OCP原则支持不足；工厂方法模式完全支持了OCP原则，使用的机制是继承；工厂方法模式都完全支持OCP原则；LSP原则是OCP成为可能的重要原则，抽象工厂模式、工厂方法模式完全遵守LSP 2008-05-06 设计模式 坚强2002 博客园 http://www.kuqin.com/design-patterns/20080504/7815.html 简单工厂模式的缺点也正体现在其工厂类上，由于工厂类集中了所有实例的创建逻辑，所以“高内聚”方面做的并不好。另外，当系统中的具体产品类不断增多时，可能会出现要求工厂类也要做相应的修改，扩展性并不很好。本人将上文中导出数据部分转换为用工厂模式的方法实现 2008-05-04 设计模式 姜敏 博客园 http://www.kuqin.com/design-patterns/20080504/7811.html 合同相当于图中的采购订单，Portfolio则与图中的合同概念有一点类似。Portfolio更象是一种松散、随意的分组，把符合条件的订单包含进来进行一些统计分析，这样的功能可以使用数据分析(OLAP)的工具实现，如果在产品中考虑也不应当成为概念模型中的一个主要对象。 2008-05-04 设计模式 RicCC 博客园 http://www.kuqin.com/design-patterns/20080504/7810.html 库存交易、交易明细是核心表；库存期间所表现的业务模式基本是行业通用的操作标准；交易来源类型、交易类型是为了跟踪交易，对交易进行运算的规则设置，他们可以设计的更复杂、灵活；针对交易类型，SAP采用移动类型来解决，基本效果也类似于此 2008-05-04 设计模式 RicCC 博客园 http://www.kuqin.com/design-patterns/20080504/7809.html 相对于单类方式，策略模式降低耦合带来更多一点灵活性；参数化方法可以减少派生类的数量；解释器针对特定方面进一步加强参数法方法的表现力。对于类似工资计算的过账规则，采用策略模式+参数化方法+解释器可以做的比较灵活。 2008-05-04 设计模式 RicCC 博客园 http://www.kuqin.com/design-patterns/20080504/7808.html 度量是对数量模式的进一步抽象，书中以体检为例，进行一次体检就是得到一组各方面的度量数据。度量模式虽然使用度量类型带来了更大的灵活性通用性，但考虑的仍然是 数量+单位 这种测量类型。以色盲这一体检项目为例，它仍是一个评测指标，但评测结果一般表现为一组可选 2008-05-04 设计模式 RicCC 博客园 http://www.kuqin.com/design-patterns/20080504/7807.html 概念模型较难说清楚，概要性描述：最直观的例子是组织结构，上级组织与下层组织之间的关系，从具体层面讲是一种所属关系，Martin将它抽象为一种责任关系。人和组织之间的所属关系是责任关系；管理者与部署之间的关系是责任关系；部门与部门负责人、经理之间的关系是责任 2008-05-04 设计模式 RicCC 博客园 http://www.kuqin.com/design-patterns/20080504/7806.html 第一篇 责任模式 Accountability,典型运用场景是组织结构的设计；第二篇 测绘与度量 Observations and Measurements，主要处理数量、单位、单位转换方面问题；第三篇 库存和帐务 Inventory and Accounting，主要是库存、财务、金融系统的Transaction设计方面问题…… 2008-05-04 设计模式 RicCC 博客园 http://www.kuqin.com/design-patterns/20080422/7341.html 在OOP中代码应该遵守开放-关闭的原则：即对修改关闭，对扩展开放。策略模式是除了继承之外的一种弹性替代方案，如果你使用继承定义了一个类，下面有部分的派生类，此时你会让基类所困住，要想修改它特别不容易，而策略模式则可能通过组合不同的对象来改变行为。 2008-04-22 设计模式 姜敏 博客园 http://www.kuqin.com/design-patterns/20080415/6758.html 本文内容包括：1.为什么我们过早的纠缠于细节？问题的本质是什么？2.救命稻草--Martin Fowler的三层视角理论3.三层视角--回头再说OO设计原则。在面对对象设计开发过程中以概念 规约 实现三个视角类思考问题能提高我们的设计能力，避免过早陷入细节泥沼。 2008-04-15 设计模式 坚强2002 博客园 http://www.kuqin.com/design-patterns/20080410/6433.html 等级权限系统在论坛中很常见，在这种系统中，权限如同官阶从低到高排列，每个用户对应一个权限；我们需要将版主权限控制在一版之内，这时我们需要范围限制权限系统；范围限制单项权限系统典型应用如工作流和OA系统 2008-04-10 设计模式 如坐春风 BlogJava http://www.kuqin.com/design-patterns/20080410/6425.html 对象是拥有责任的实体，封装是任何形式的隐藏。它可以隐藏数据，还可以隐藏实现细节、派生类或其他。设计模式中的Adapter模式，它有类的Adapter模式和对象的Adapter模式，它就展示了多种封装：类(数据，方法，子类) 、对象(其他对象)。 2008-04-10 设计模式 ZH-CN 博客园 http://www.kuqin.com/design-patterns/20080407/6162.html 如何在一个大型遗留系统的基础上组织和运作重构项目，从而切实有效地改善系统质量。大规模遗留系统的重构一直是困扰众多软件组织的难题，大型系统中的质量问题是经年累月堆积下来的，要解决这些问题也只能从价值最高的地方入手，耐着性子一点点重新恢复代码质量。 2008-04-07 设计模式 熊节 捷道·敏捷堂 http://www.kuqin.com/humor/20080403/5794.html 我在Java论坛看到这篇文章，作者以轻松的语言比喻了java的32种模式，有很好的启发作用，但可惜没有给出具体的意思，我就在后边加上了。这些都是最简单的介绍，要学习的话建议你看一下阎宏博士的《Java与模式》一书。 2008-04-03 IT幽默 不详 互联网 http://www.kuqin.com/humor/20080403/5782.html 程序编程思想就像武学招数一样，需要融会贯通，本文看看他们有哪些雷同：一、逆向工程；二、泛型算法；三、结对编程；四、架构设计；五、过度设计；六、Base64 2008-04-03 IT幽默 ern 互联网 http://www.kuqin.com/design-patterns/20080331/5533.html 设计原则是基本的工具，应用这些规则可使代码更加灵活、更容易维护，更容易扩展。基本原则：封装变化Encapsulate what varies. 面向接口变成而不是实现 Code to an interface rather than to an implementation. 优先使用组合而非继承 Favor Composition Over Inheritan 2008-03-31 设计模式 坚强2002 博客园 http://www.kuqin.com/design-patterns/20080324/5032.html 对于C++开发语言，我个人推荐采用返回值的方式来表达运行结果情况而用out参数（指针或引用）承载实际内容。对简单的情况，返回值可以是bool类型，但更多的时候推荐使用枚举（或int）。任何函数在执行之初对传入参数和运行环境的基本检查是必需的，这是一个非常好的习惯 2008-03-24 设计模式 张友邦 CSDN博客 http://www.kuqin.com/design-patterns/20080323/5031.html 不要让错误传播，在错误出现的发源地（萌芽期）就解决它！错误越是传播到最后，关于处理它的上下文就丢失得越多，对于错误的蔓延就越是爱莫能助！ 2008-03-23 设计模式 zhuweisky 博客园 http://www.kuqin.com/design-patterns/20080315/4537.html 不要为了UML而去UML；UML只是交流工具，交流清楚了就可以扔掉了；在画UML图形时应该能够想像到对应的代码实现，否则就别画了。 2008-03-15 设计模式 峻祁连 博客园 http://www.kuqin.com/design-patterns/20080302/4125.html 对于开封原则，事实上没有任何一个程序可以做到完全的100%的封闭，在不能封闭的时候必须有所选择，有所放弃。包括其它原则或设计模式亦是如此。如果目前没有更好的解决方案，那么可行的方案便是最好的方案。正如草根树皮不是美味，但在饥饿的情况下，也是最好的选择。 2008-03-02 设计模式 sban 博客园 http://www.kuqin.com/design-patterns/20080302/4124.html 本文将探讨在分层模式下实现Lazy Load所遭遇的困难与迷思，并重点探索模式背后隐藏的思想和设计原则。文章的最后将对书上给出的三种Lazy Load作一个简单的分析和比较。 2008-03-02 设计模式 1-2-3 博客园 http://www.kuqin.com/design-patterns/20080302/4123.html 本文通过由Active Record模式到Data Mapper模式(使用工厂方法)再到Data Mapper模式(使用MapperRegistry)的一系列重构，探讨模式背后隐藏的思想和面向对象设计原则。本系列的要点是：重要的不是如何做，而是为什么做。 2008-03-02 设计模式 1-2-3 博客园 http://www.kuqin.com/design-patterns/20080301/4085.html 设计模式本身其实不像有些人说是种思想, 只是它介绍的那些手法体现了一些思想. 对于SICP这样的基础入门书籍(是本大学教材), 这些思想是一上来就强调的. 不过大多数命令式和面向对象语言使用者, 看起来不习惯罢了. 老外有篇文章, 大谈特谈如果用FP编程, 设计模式根本不存 2008-03-01 设计模式 怪怪 博客园 http://www.kuqin.com/design-patterns/20080301/4084.html 在设计中, 尤其是数据驱动的设计中, 既要考虑对现实世界的抽象, 也要考虑对计算机世界的抽象. 软件部分面向对象的产物与其它已知结构的冲突(比如与数据库设计的冲突), 其原因是没有把计算机世界某一部分就软件所处理的问题域进行再次的合理抽象, 或者太轻易的处理了它 2008-03-01 设计模式 怪怪 博客园 http://www.kuqin.com/design-patterns/20080301/4083.html 如果真的坚持正确的职责，那么该贫血的模型必须贫血；如果充上别人的血，对于其他对象来说这个对象倒是高聚低耦了，但估计如果你不是AOP迷，这个对象本身就难免成为胶水对象，比如你可以考虑把CommunityServer的Threads类的职责放到Thread类上去是个什么景象。 2008-03-01 设计模式 怪怪 博客园 http://www.kuqin.com/design-patterns/20080229/4047.html 性能调优依赖的技术包括两个方面：程序设计人员（调整应用程序）和基础服务维护人员（调整应用服务器，数据库应用和硬件服务） 2008-02-29 设计模式 Anders小明 BlogJava http://www.kuqin.com/design-patterns/20080229/4042.html 我们在餐馆吃饭的时候，一般都是在拿到菜单后，选择喜欢的菜，然后通知服务员。服务员会将我们的定单交给大厨，大厨可能会亲自去做这道菜，也可能安排给小厨来做，总之，我们不用担心他们没有人做菜，即使有时候等的时间长点。 2008-02-29 设计模式 Anders Cui 博客园 http://www.kuqin.com/design-patterns/20080228/4003.html 纵向关系就是继承关系，它的概念非常明确，也成为OO的三个重要特征之一，这里不过多的讨论。横向关系较为微妙，按照UML的建议大体上可以分为四种：依赖，关联，聚合，组合。它们的强弱关系是没有异议的：依赖 弱于 关联 弱于 聚合 弱于 组合 2008-02-28 设计模式 floodpeak 博客园 http://www.kuqin.com/design-patterns/20080228/4002.html 高手自言自语：是啊，你不受GOF设计模式的束缚，不强迫自己往他给定的UML类图上靠，而思想上却是相通的，小伙儿有前途。听了高手这一顿白话，我信心倍增。高手看我信心爆膨，说：别高兴的太早，刚才客户又有新的需求了，这回看你能不能瞎猫碰到死耗子身上，给我整出来。 2008-02-28 设计模式 Game_over 博客园 http://www.kuqin.com/design-patterns/20080228/4001.html 看了设计模式后，只是知道概念，却不知道如何运用，貌似理解，实则不然。我就打算写一个例子，把经常会见到的模式都能体现出来，就从今天做起吧。 2008-02-28 设计模式 Game_over 博客园 http://www.kuqin.com/design-patterns/20080119/3778.html 我们常常将接口与抽象类混淆，事实上，两者的表象过于一致。但接口用来定义两个对象通信的契约，抽象类用来封装对象间公用的行为；抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。二者设计起初的目标完全不同，但在实际应用中被太多的人误解。 2008-01-19 设计模式 浩淼 CSDN博客 http://www.kuqin.com/design-patterns/20080106/3507.html 《大话设计模式》相关主题和小菜编程成长记系列文章。 2008-01-06 设计模式 程杰 《大话设计模式》 http://www.kuqin.com/design-patterns/20080106/3506.html 这是大鸟我的认为，《设计模式：可复用面向对象软件的基础》、《重构：改善既有代码的设计》、《Java与模式》、《重构与模式》我认为是设计模式的四大名著，本来想把《敏捷软件开发：原则、模式与实践》也列入的，但考虑到《Java与模式》是国人之经典…… 2008-01-06 设计模式 程杰 博客园 http://www.kuqin.com/design-patterns/20080106/3505.html 门面模式要求一个子系统的外部与其内部的通信必须通过一个统一的门面(Facade)对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。 2008-01-06 设计模式 程杰 博客园 http://www.kuqin.com/design-patterns/20080106/3504.html ‘迪米特法则（LoD）’也叫最少知识原则，简单的说，就是如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。 2008-01-06 设计模式 程杰 博客园