Brookes的专栏

今天新加了一个软件工程的分类。准备陆续写一些文字。不过，不过不会局限于Sofeware Engineering，还会涉及到OOA/OOD、UML/Modeling、Design Pattern、Project Management等等吧。最近两年，其实已经渐渐远离了Coding的工作，更多的在分析、建模和项目的管理上，慢慢的有了一些积累。不过，我对文档的管理不是很在行，也一直没找到一个很好的工

  一. 生成器模式简介　　生成器模式也有称为建造者模式。生成器模式的意图在于将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示（GoF）。在软件设计中，有时候面临着一个非常复杂的对象的创建工作。这个复杂的对象通常可以分成几个较小的部分，由各个子对象组合出这个复杂对象的过程相对来说比较稳定，但是子对象的创建过程各不相同并且可能面临变化。根据OOD中的OCP原则，我们自然应

 一. 抽象工厂模式概述 　　抽象工厂模式是工厂模式中最一般、最抽象的一种表现形式，是对工厂方法模式的进一步扩充。工厂方法模式可以对一类产品的建造进行管理，将建造具体产品的建造过程交给到具体的子类中完成。如果需要管理两类及以上产品的建造过程呢？当然很自然的就可以想到可以使用多个工厂方法实现。这样做的问题在于，一是导致工厂过于分散不好管理；二是这几类产品之间如果存在密切的关系，他们的建造过程并不

 一. 简单工厂模式概述 　　简单工厂模式并不是GoF《Design Patterns》一种中描述的23种设计模式之一，但是包含在了Cooper的《Introduction to Desgin Patterns in C#》中。可以毫不夸张的说，简单工厂模式是目前应用最多的模式。　　简单工厂模式处理的是这样一种问题：有一系列功能及其相似的产品，在客户看来完全可以互相替代。客户需要使用的是其中一个产

什么是设计模式？通常会有以下几个定义：设计模式描述了软件设计过程中某一类常见问题的一般性解决方案。面向对象设计模式描述了面向对象设计过程中，特定场景下，类与相互通信的对象之间常见的组织关系。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次的使用该方案而不必重复劳动。说到设计模式，首先必须提到的就是GoF，1994年，Erich G

设计模式（Design Patterns）相关的文章很多很多，csdn，博客园，很多原创的或者转载的。这样看来，我是没必要再来画蛇添足的——这个说法不确切，那些蛇本来就不是我画的，而是GoF，Cooper，还有许许多多的前辈。其实，我知道Design Patterns不算晚，也曾有一段时间言必称模式，不过，真的应用到我的实际项目中的，却没有多少。所以，因了资历的限制，还不能说理解二字。现在重新

一. 工厂方法模式简介　　在简单工厂模式中，由一个工厂类（实际上是其中的某一个具体方法）负责决定实例化哪一个具体产品，从而接触客户和具体产品类直接的依赖关系。而工厂方法模式对这种思想进行了进一步的扩展，把这个实例化产品的方法抽象化（从而也抽象化了这个工厂类），把实例化哪一个具体产品类的决策延迟到它的子类中去。也就是说，这个抽象方法只定义了应该创建一个什么类（抽象），让子类去决定创建哪一个对象。

【转帖说明】这是2003年在JavaWorld.com上的一篇文章，这其实是《Holub on Patterns》这本书中的一个章节。全文的核心思想就是使用接口，不要使用继承，可说是对CARP原则的注解。Why extends is evilImprove your code by replacing concrete base classes with interfacesBy Al

在面向对象大师Robert C. Martin的《Agile software development: Principles, Patterns and Practices》一书中，只把前面提到的OCP、LSP、SRP、DIP和ISP列为OOD的设计原则。确实，这几个原则是面向对象设计中基石性的原则。在我看来，不能明了这些原则的本义，是根本谈不到OOD的。而后面的LoD、CARP也被广泛传播，尤

 合成/聚合复用原则（Composite/Aggregate Reuse Principle, CARP）也可以简称为合成复用原则（Composite Reuse Principle, CRP）。合成（Composition）和聚合（Aggregation）起司和都是对象建模中关联（Association）关系的的一种。聚合表示的是整体和部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离部

迪米特法则（Law of Demeter, LoD）又叫最少知识原则（Least Knowledge Principle, LKP）。1987年秋天由美国Northeastern University的Ian Holland提出，被UML的创始者之一Booch等普及。后来，因为在经典著作《 The Pragmatic Programmer》而广为人知。 迪米特法则可以简单说成：talk onl

 接口隔离原则（Interface Segregation Principle）是Robert C. Martin(!)在1996年为《C++ Reporter》所写的专栏Engineering Notebook的第四篇（原文)，这个原则说的是如何处理接口“臃肿”带来的麻烦。这个原则概括起来只有一句话：Clients should not be forced to depend upon meth

依赖倒置原则（Dependency-Inversion Principle）是Robert C. Martin(!)在1996年为《C++ Reporter》所写的专栏Engineering Notebook的第三篇（原文)，后来加入到他在2002年出版的经典著作《Agile Software Development Principles Patterns and Practices》 中提到的，

 单一职责原则（Single Responsibility Principle，SRP）最初是谁提出的我没有考证，不过大师Robert C. Martin对SRP的解释是：Each class should have one and only one reason to change.一个类只能因为一个因素而改变。SRP说的其实是类设计时的职责划分和粒度问题。没个类都是因为具有一定的职责才

里氏替换原则（Liskov Substitutiion Principle，LSP）被称作继承复用的基石，它的提出甚至要早于OCP。不过遗憾的是，由于对这一原则的理解各不相同，经过多次的翻译、转述，LSP成了OOD设计原则中争议最多的话题之一。其实早在1987年的OOPSLA大会上，麻省理工学院（MIT）计算机科学实验室的Liskov女士就发表了经典文章Data Abstraction and

开闭原则OCP（Open-Close Principle）被称作是OOD的基石，是OOD最重要的原则之一。这个原则由大师Bertrand Meyer在1988年提出（汗，那个时候恐怕国内还很少人知道OO，甚至计算机为何物）：Software entities should be open for extension,but closed for modification。多简单啊？！这个原则的

        在我想记录些什么的时候，首先想到的就是这些OOD的原则。坦白的说，我自己对这些原则的理解也只能算是一知半解。自己做OOD也算有些年头了，但是在实际项目中，真正按这些原则所要求的那样去设计，我自知还没有达到那个高度。而这些原则就像是这几年年一直大热的设计模式一样，并不能拿来就用，“拼装”出合格的设计或代码；也不能拿着这些做标尺，一个个去检查那些设计和代码。但是，这些原则之所以能成立，

一. 原型模式简介　　原型模式（Prototype Pattern）也是一种创建型模式，它关注的是大量相似对象的创建问题。我们经常会遇到这样的情况：在系统中要创建大量的对象，这些对象之间具有几乎完全相同的功能，只是在细节上有一点儿差别。　　这样的情形经常遇到。三国系列游戏是我最喜欢的游戏系列之一。你有没有注意到那里边上百位英雄的头像基本上很相似？你仔细区分就会发现，虽然每个人都不同，但基本上只具有