充满诗意的联盟

  你是一个优秀软件开发人员吗？你知道GRASP吗？GRASP软件开发模式，全称通用职责分配软件模式（General Responsibility Assignment Software Patterns），是与著名的软件模式GoF（Gang of Four，即我们常说的那23种软件开发模式）齐名的另一种软件开发模式。但是与GoF不同的是，它并不是提出一些具体的软件组织结构，而是提出，在将现实世界...

也许你是一位项目经理，也许你是一位项目骨干成员，或者开发小组长。在我发表“如何提高代码质量”的这一系统文章后，有许多网友都向我抱怨，说他无法把握整个项目组成员的代码质量。我想，这也是所有项目组普遍存在的问题吧，它通常表现为以下几个问题：软件项目普遍存在的问题 1）新手。任何项目组成员都不可避免地出现新手，他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短，往往技术不成熟，没有形...

终于到了该说说领域驱动设计的时候了。我们在这场关于代码质量的讨论中，从代码可读性开始，讨论了代码复用性、设计模式，然后探讨了职责驱动设计。代码可读性是对代码质量最基本的要求，可惜我们仍有做得不够的（即使那些开发程序很多年的老程序员）。代码复用是提高代码质量的最初级阶段，但是在一个多人开发的项目团队中，围绕代码复用值得讨论的问题依然非常多，它依然是一个非常复杂的问题，甚至有时它不再仅仅是一个技术问题...

3）职责驱动设计和领域驱动设计 前面我提到，当我们尝试写一些复杂功能的时候，我们把功能分解成一个个相对独立的函数。但是，应当将这些函数分配到哪个类中呢？也就是系统中的所有类都应当拥有哪些函数呢？或者说应当表现出哪些行为呢？答案就在这里：以职责为中心，根据职责分配行为。我们在分析系统时，首先是根据客户需求进行用例分析，然后根据用例绘制领域模式和分析模型，整个系统最主要的类就形成了。通过以上分析形...

3.可变更性 前面我提到了，软件的变更性是所有软件理论的核心，那么什么是软件的可变更性呢？按照现在的软件理论，客户对软件的需求时时刻刻在发生着变化。当软件设计好以后，为应对客户需求的变更而进行的代码修改，其所需要付出的代价，就是软件设计的可变更性。由于软件合理地设计，修改所付出的代价越小，则软件的可变更性越好，即代码设计的质量越高。一种非常理想的状态是，无论客户需求怎样变化，软件只需进行适当...

今天这堂培训课讲什么呢？我既不讲Spring，也不讲Hibernate，更不讲Ext，我不讲任何一个具体的技术。我们抛开任何具体的技术，来谈谈如何提高代码质量。如何提高代码质量，相信不仅是在座所有人苦恼的事情，也是所有软件项目苦恼的事情。如何提高代码质量呢，我认为我们首先要理解什么是高质量的代码。高质量代码的三要素 我们评价高质量代码有三要素：可读性、可维护性、可变更性。我们的代码要一个...

2.   复用性（上接）在软件开发过程中，其实很多要实现的功能都具有相同或者相似性。当你开发完一段代码后，你发现这段代码可以用到另一个程序中，这时复用就出现了。最简单的复用就是代码拷贝，将一段代码拷贝到另一个地方使用。代码拷贝应当是最低级别的复用，因为它可维护性差，当这段代码因为某种原因需要修改时，这种修改就变成了可怕的梦魇。将同样的代码在几十甚至上百处进行同样的修改。这样的修改也许我们大多数都...

前面讲了为什么我们要使用分析模型，现在我们看设计分析模型的基本原则。分配职责和职责驱动设计 我们在开始分析模型的时候，首先要弄清楚一个非常重要的原则，就是以职责为中心。OO分析设计的核心原则之一，就是软件系统中的所有元素都必须具有高度相关的职责，也就是说，软件系统中所有的模块、包、对象类，都应当拥有一个清晰的职责，并且与它相关的所有元素（即模块中的所有包、包中的所有对象类、对象类中的所有...

——对分析模型的一点儿见解 当需求分析结束、需求确认完成、需求讨论告一段落的时候，我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型，需求分析阶段结束，开始进入开发阶段。但是，这时候虽然需求分析阶段结束了，却千万不要以为需求分析就结束了，如果你还这样认为，说明你还没有摆脱瀑布式开发的思维。瀑布式开发的思维的关键点就是认为，需求分析阶段应当完成所有的需求分析和确认的工作，否认需求...

前面我们讲了如何从业务领域获取知识，创建领域模型，那么建立领域模型应当注意什么呢？建立领域模型应当注意的问题1．领域模型不是数据模型，也不是软件对象模型一个创建领域模型的过程中非常容易犯的错误就是，将领域模型当成了数据模型，或者软件对象模型。领域模型，又称为概念模型、领域对象模型或分析对象模型，是“专用于解释业务领域中重要的‘事物’和产品”[RUP]。领域模型专注于现实世界的对象（概念...

前面我们讲了如何建立用例模型，那么建立用例模型应当注意什么呢？建立用例模型应当注意的问题 给大家几个建立用例模型中常出现的问题和应对遵循的原则：一．如何发现用例经过以上的讲解，相信大家对建立用例模型有了一个整体的概念，然后开始着手练习绘制用例模型。这时候，一个非常严峻的问题出现了：如何发现用例。大师曾经给出了答案，大致意思就是：首先选择系统边界，然后确定主要参与者，定义满足用...

——对用例模型及其应用的一次有益的探讨前言：这是一次对用例模型的探讨。怎样建立用例模型，怎样编写用例说明，它与需求规格说明书有什么区别，它能替代需求规格说明书吗？也许在这里可以找到你要的答案。 进入软件业稍微久一点儿的人恐怕都不会陌生，软件开发的最初阶段都是谈需求、写需求规格说明书。需求规格说明书是与客户最终确认到纸上的，非常正式的公文。软件开发应当做什么，做成什么样子，什么东西不...

前面提出了软件开发的轮回：期望——破灭——崩溃——新的轮回，我们的解决之道在哪里呢？我的反思——不在沉默中爆发，就在沉默中灭亡反思，我在反思…… 对于来自客户的变更，我永远忘不了的是大学时老师的谆谆教导。上软件工程课的时候，老师总是一再地反复强调，一定要将需求变更消灭在需求分析阶段。按照过去的瀑布式开发理论的描述，总是要求我们在需求分析阶段了解清楚客户的所有需求，并编写成《软件...

——对软件分析设计的一次深刻反思与探讨 前言：你干软件开发多少年了？你是否开始感到困惑了、累了、算了？你是否该找一个加州旅馆好好歇一歇脚了？这篇文章也许就是你的加州旅馆，它给你解惑，反思软件开发中出现的问题，探讨解决这些问题的办法，那就是建立模型——用例模型、领域模型、分析模型和设计模型。 谈起软件开发，我在10年前就开始了。那时天是蓝的，生活是美好的，程序设计也是轻松愉快...

  最近网友Uranus问我了一个非常有趣的问题：设计模式GRASP和GoF是怎样解决耦合的问题？实际上虽然同是设计模式，解决对象间耦合的问题都是它们的终极目标，但是它们在解决它们的方式上却是完全不同的，GRASP是从整体设计上解决耦合的问题，而GoF却是从具体实现上解决的，在这里我们不妨探讨一下。设计模式GRASP其名称翻译过来就是“通用职责分配设计模式”，从字面上我们不难发现，“职责分配”是G...

  当我们分析清楚客户需求设计出用例模型以后，当我们分析清楚客户的业务环境制作出领域模型以后，当我们综合用例模型、领域模型和我们的聪明才智设计出一个又一个的类和它们各自的方法以后，当就在一切都准备就绪只欠东风的关键时刻，一个对象发出了撕心裂肺的怒吼——谁来创建我？！！！一个对象，不管拥有多么强大的功能，不管进行了多么精巧的设计，如果不能被创建，就如同韩信不能做将军，孙膑不能当军师，勾践不能回越国，...

在上一章《（原创）一个优秀软件开发人员的必修课：GRASP（2）低耦合》中我聊了聊低耦合，今天我想再聊聊与低耦合休戚相关、GRASP的另一个重要的模式：高内聚。 2.高内聚（High Cohesion）高内聚是另一个普遍用来评判软件设计质量的标准。内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该...

我偶然在google或yahoo这样的搜索引擎搜索GRASP发现，除了国外的网站，国内网站多介绍和讨论GoF而很少介绍GRASP，即使这少量的文章也讲解非常粗略。个人认为作为优秀的开发人员，理解GRASP比GoF更重要，故写此文章。前面我在《（原创）一个优秀软件开发人员的必修课：GRASP软件开发模式浅析》中介绍了使用GRASP的目的，今天允许我调换一下顺序，先从低耦合讲起，因为诸如创建者模式、信...

[b]前言：[/b]你写过用例模型吗？也许有；你写过领域模型吗？也许还没有。在这里，我们可以尝试写写领域模型，看看它的作用、带给我们的好处。随着RUP在中国的传播，人们开始尝试用RUP统一过程来指导软件的设计和开发，但这些尝试并不成功。比较普遍的，大家都开始使用用例模型来进行需求阶段的分析和设计了。当然，能做出第一步已经非常不错了，但这远远不够。要做好需求分析，用例模型可以帮助我们分析清楚...