华仔-技术博客

NOP，No Overdesign Priciple，不要过度设计原则。 这应该是你第一次看到这个原则，而且你也不用上网查了，因为这个不是大师们创造的，而是我创造的：） 之所以提出这个原则，是我自己吃过苦头，也在工作中见很多人吃过类似的苦头。 你可能也见过这样的场景：产品提出了一个需求，设计师眼光非常长远，他甚至把5年后可能的业务变化都提出来并且加以设计了，让你不得不佩服设计师的高瞻远瞩的眼光，并

DIP，dependency inversion principle，中文翻译为“依赖倒置原则”。 DIP是大名鼎鼎的Martin大师提出来的，他在1996 5月的C++ Reporter发表“ The Dependency Inversion Principle”的文章详细阐述了DIP原则，并且在他的经典著作《 Agile Software Development, Principles, Pa

完成领域类到软件类的转换，这就是面向对象领域设计阶段的主要任务。经过领域模型的分析后，面向对象已经初具雏形，但领域类并不能指导我们进行编码工作，因为领域类只是从用例模型中提炼出来的反应业务领域的概念，而并不是真正意义上的软件类。 “革命尚未成功，同志还需努力”，我们需要再进一步，完成领域类到软件类的转换，这就是面向对象领域设计阶段的主要任务。 设计阶段是整个面向对象分析和设计的高潮阶段。在设计阶段

类模型设计其实就是程咬金打天下 -- 三板斧 而已 ：）第一斧（照猫画虎）：领域类映射面向对象类设计首先要解决的一个问题是：类从哪里来 ？有的人可能会认为，要发挥想象力、创造力。。。。。等各种“力”——这种方法的主要问题是：我们不是在进行纯粹的艺术创造，而是要最终满足客户需求，而不能天马行空。有的人可能会想到，参考其它的系统吧，把类似系统拿过来改吧改吧 ——这种方法的主要问题是：如果没有其它类似系

领域模型是面向对象分析和设计的第一步！！完成了需求分析之后，我们已经有了一个良好的开端，但我们的主角“面向对象”还不见踪影。前面我们提到，需求分析和面向对象是没有直接关系的，需求分析阶段是不区分是面向对象还是面向过程，那么什么时候才真正开始面向对象的工作呢？ 答案就在本章：领域建模。从领域模型开始，我们就开始了面向对象的分析和设计过程，可以说，领域模型是完成从需求分析到面向对象设计的一座桥梁。 领

前面详细阐述了“高内聚低耦合”的总体设计原则，但如何让设计满足这个原则，并不是一件简单的事情，幸好各位前辈和大牛已经帮我们归纳总结出来了，这就是“设计原则”和“设计模式”。毫不夸张的说，只要你吃透这些原则和模式并熟练应用，就能够做出很好的设计。==================================================================【SRP原则详解】SRP

类模型指导我们如何声明类，动态模型指导我们如何实现类！动态模型设计一般都是在类模型设计完成后才开始，因为动态模型设计的时候一般都需要用到类模型中的类。相对类模型来说，动态模型要相对简单一些，主要原因在于动态模型设计的时候没有什么设计原则和设计模式需要应用，只需要对照用例模型，根据用例模型的特点，选取一个合适的动态模型将其表述出来即可。动态模型在实际开发过程中有非常重要的作用，简单来说，如果没有动态

前面通过实例讲解了一个一环扣一环的面向对象的开发流程：用例模型 -> 领域模型 -> 设计模型（类模型 + 动态模型），解答了面向对象如何做的问题。接下来我们就要讲“如何做好面向对象设计”的技巧了===================================================================参考维基百科的解释，内聚的含义如下：cohesion refers t

用例图是用来描述系统的，而SSD（系统序列图）又是来描述用例的，oh my god，这不是在玩我们么？System Sequence Diagram，缩写为SSD（注意不要与SSD硬盘混淆），中文翻译为“系统顺序图”，主要用于描述某个用例的某个分支场景下，外部参与者与系统的交互过程。简单来说：SSD就是用例的可视化描述。 细心的朋友可能会发现，前面我们在介绍“用例方法”的时候说不需要画图，这里又说

高内聚低耦合，可以说是每个程序猿，甚至是编过程序，或者仅仅只是在大学里面学过计算机，都知道的一个简单的设计原则。虽然如此流行和人所众知，但其实真正理解的人并不多，很多时候都是人云亦云。===============================================================要想真正理解“高内聚低耦合”，需要回答两个问题：1）为什么要高内聚低耦合？2）高内聚低耦合

ISP，Interface Segregation Principle，中文翻译为“接口隔离原则”。和DIP原则一样，ISP原则也是大名鼎鼎的Martin大师提出来的，他在1996年的C++ Reporter发表“ The Interface Segregation Principle”的文章详细阐述了ISP原则，并且在他的经典著作《 Agile Software Development, Pri

需求分析有三种级别，你自认为属于哪一级呢 ？需求分析的目的是什么？ 你可能会毫不犹豫的回答：需求分析的目的当然是了解客户需要什么！ 这个回答看起来是毫无疑问的，我们当然要了解客户需要什么，我们才能给他们做出他们想要的。但只做到这样就可以了么？ 我们来看一个简单的需求，客户找到你说：“我要一只羊！”这个需求够简单吧？那你是不是毫不犹豫的就抓一只羊给客户呢？

又是设计原则，又是设计模式，到底该用哪个呢？ =============================================================================在“设计模型”一章中，我们提到设计原则和设计模式是互补的，设计原则和设计模式互补体现在：设计原则主要用于指导“类的定义”的设计，而设计模式主要用于指导“类的行为”的设计。 举一个很简单的例子：假设我们

掌握了设计模式之道后，我们将以全新的方法来理解设计模式，这个方法更简单、更直观，不信？看几个样例就知道了=====================================================================【业务】假设你进入了一个信息安全管理非常严格的公司，这家公司不允许员工自行打印文档，所有的文档打印都需要交给文档打印系统统一管理。文档打印系统会记录每次打印的

很多人能够熟练背诵出所有的设计模式，能够快速画出各种设计模式的UML类图，也能够熟练的写出《设计模式》一书中各个模式的样例代码。但一到实际的项目设计和开发的时候，往往都会陷入迷茫：要么无从下手，不知道哪个地方要用设计模式；要么生搬硬套，胡乱使用设计模式，将方案和代码搞得一团乱麻。============================================================

经过前面深入的阐述，SOLID的原则我们已经基本上讲清楚了，但如果想熟练的应用SOLID原则，仅仅知道SOLID是什么（what）还不够，我们还需要知道SOLID原则在什么时候和什么场景应用（when或where）。

“设计模式”这个词几乎成为了软件设计的代名词，很多人非常天真的以为掌握了设计模式就掌握了软件设计，但实际上如果只是握了设计模式，软件设计的门都还没摸到！========================================================谈起设计模式，那是几乎无人不知，无人不晓，大名鼎鼎的“GOF”（中文有的翻译为“四人帮”）惊世之作，真是“平生不识GOF，学尽设计也枉然

LSP，Liskov substitution principle，中文翻译为“里氏替换原则”。 这是面向对象原则中唯一一个以人名命名的原则，虽然Liskov在中国的知名度没有UNIX的几位巨匠（Kenneth Thompson、Dennis Ritchie）、GOF四人帮那么响亮，但查一下资料，你会发现其实Liskov也是非常牛的：2008年图灵奖获得者，历史上第一个女性计算机博士学位获得者。其

OCP，Open-Closed Principle，中文翻译为“开闭原则”。 当我第一次看到OCP原则时，我的感觉就是这原则也太抽象了吧，什么开，什么闭呢？ 然后我去寻找更加详细的答案，最经典也是最常见的解释就是维基百科了：http://en.wikipedia.org/wiki/Open/closed_principle "software entities (classes, modules,

面向对象设计和弹吉他差不多，有很多成熟的理论和技巧，学会弹吉他并不难，但要成为吉他高手或者大师，还是要靠个人天分！【师傅领进门，修行在个人】“类模型”是整个面向对象设计模型的核心，是面向对象设计阶段的主要输出，也是设计师们最能够发挥自己才能的地方。 虽然“类模型”如此重要，但面向对象设计技术经过几十年的发展后，目前已经形成了很成熟的一套体系，因此真正在进行“类模型”设计的时候，其实难度并不高，这也

看起来有点不可思议，需求阶段“白纸黑字”的用例文档，经过我们一步一步的操作，逐步就得到了“图形化”的领域模型，面向对象初具雏形。领域建模的三字经方法：找名词、加属性、连关系。 我们接下来以一个样例看看领域模型具体如何建模。1.1. 找名词我们以POS机买单的用例来看看具体如何建领域模型。 首先，将用例中所有的名词挑选出来（如下用例文档中蓝色加粗的词组）：【用例名称】买单【场景】Who：顾客、收银员

从理论的角度对比“面向对象”和“面向过程”两种编程思想的差异，提出了面向对象的程序 = 对象 + 交互 的新颖说法

Simula 面向对象技术最早是在编程语言Simula中提出的。1967年5月20日，在挪威奥斯陆郊外的小镇莉沙布举行的IFIP TC-2 工作会议上，挪威科学家Ole-Johan Dahl和Kristen Nygaard正式发布了Simula 67语言。Simula 67被认为是最早的面向对象程序设计语言，是面向对象的开山祖师，它引入了所有后来面向对象程序设计语言所遵循的基础概念：对

为什么要面向对象？可以说，面向过程和计算机是如影随形的。从计算机诞生之日起，面向过程就是占据着主导地位的思想，即使到了现在，面向过程也是无处不在的，C语言、操作系统、协议栈、驱动系统，都是面向过程的代表。 那为什么还会有面向对象的诞生并流行呢？当然是面向过程存在某些不足，如果面向过程足够好，谁还费心费力的去搞另外一套呢？ 前面我们提到，面向过程是一种机器的思想，我们以流水线作为类比，那

抽象类是一种特殊的类，其特殊性在于抽象类只能用于继承，不能被实例化为具体的对象。例如在Java中不能new一个抽象类，但可以extends一个抽象类。 抽象类的定义其实很简单，但其使用并不那么简单，有几个问题我们需要深入研究一下。 第一个问题是：有了类，为什么还要抽象类，为什么设计一种只能继承，不能实例化的类？答案就在于：某些场景下普通类不够用。例如，“苹果”、“桔子”、“香蕉

“接口”是我见过的面向对象领域中滥用、乱用、误用最多的术语：有的人说：兄弟，给我提供一个“查询XXX”的接口。。。。。。有的人说：系统对外提供了“查询”、“插入”、“更新”、“删除”4个接口。。。。。。有的人说：我们要基于“接口”编程。。。。。。有的人说：你这样做破坏了我们的接口设计。。。。。。。。。。。。。。。。。倒不是在这里指责他们的水平有多差，而是接口这个属于的中文翻

有了“类”的清晰定义后，“对象”就比较容易理解了。对象就是一个具体的类，一个真实存在的类。前面我们提到面向对象是对现实世界的模拟，那么对象就是现实世界中存在的“物体”。 例如，“人”是一个类，我就是一个“人”的对象，你也是“人”的对象，奥巴马也是“人”的对象。。。。。。又比如：你去国美买冰箱，但国美肯定没有一个单独叫做“冰箱”的东西卖给你，而是具体的某台海尔XX型号的冰箱、西门

方以类聚，物以群分——《周易 易传》。 类是面向对象领域里最基础的一个概念，也是面向对象分析和设计的基石。 然而，如此重要的一个概念，竟然很难找到深入的说明，绝大部分介绍面向对象的书籍或者资料基本上都是这么解释的：“类是一组对象的抽象”，这个解释看起来清晰明了，但实际上犯了一个逻辑上的错误：以未明确的概念来解释待明确的概念，什么是对象，什么是抽象，我们都还不知道，你却用这个概念来解

面向对象会导致性能降低？这是一个在IT江湖流传已久的传说，很多对面向对象不甚了解、或者一知半解的人，每当需要抵触面向对象时，就会把这条“金科玉律”拿出来救驾！ 更要命的是，每个相信这个传说的人都会举一个看起来很显而易见的例子：C和Java的对比！ 你可以到网上搜索一大堆C和Java的性能对比，你自己也可以做一个简单的对比测试，我毫不怀疑测试结果肯定是C快，但这能证明面向对象导致

抽象的中文概念非常形象，简单来说就是“抽取出来比较像的部分”。 那么，在面向对象的领域里，抽取什么东西比较像的部分？ 还记得前面给类下的定义么？我们一起来回顾一下：类就是一组相似事物的统称。再结合我们对象的定义：对象就是一个具体的类，一个真实存在的类。我们就很容易发现了抽象的详细含义：抽取多个对象或者类中比较像的部分。   注：史派克：《猫和老鼠》中的斗

史前时代：面向机器最早的程序设计都是采用机器语言来编写的，直接使用二进制码来表示机器能够识别和执行的指令和数据。简单来说，就是直接编写0和1的序列来代表程序语言。例如：使用0000 代表 加载（LOAD），0001 代表 存储（STORE）等。 机器语言由机器直接执行，速度快，但一个很明显的缺点就是：写起来实在是太困难了，一旦你发现自己写错了，改起来更蛋疼！这样直接导致程序编写效率十分

很多人在分析需求的时候，采用的是东扯葫芦西扯瓢的方式，列出了很多的需求点，但当你看完后，你还是不知道到底要干嘛！！  ---- 写在前面

你知道么，用例图 不是 用来描述 用例的哦！！！！熟悉UML的朋友都肯定知道，UML有一个叫做用例图的东东。单纯从名字上来看，你可能以为用例图是用来描述用例的，即：用例图 = 用例的图形化表示。 然而各位发明ＵＭＬ的大师们，却在无意中给我们设下了一个陷阱：所谓的用例图，不是用来描述用例，而是用来描述系统的图形。 听起来有点奇怪和别扭，既然是用来描述系统的图形，为什么叫做用例图，而不叫系统图呢？ 这

很多人像老黄牛一样辛辛苦苦做了很多年软件开发，但却连“需求”到底是什么都不清楚。当然，没有人自己会承认这点！凡事都有一个开头，软件项目也不例外，对于软件项目来说，需求就是项目最开始的一个输入。 参考维基百科，需求定义如下：In systems engineering, a requirement can be a description of what a

在此要向将polymorphism翻译成“多态”的人致敬！因为多态的英文实在是太难理解了，而中文翻译得又如此形象如此贴切。 从字面意思上就可以看出，多态就是“多种形态”的意思。但仔细探究一下：“多种形态”其实还是没法很好的理解，不同的人也还是会有不同的理解。 动画片看得多的同学可能会以为：多种形态，就是很多种变身啦 ：），就像孙悟空72变一样，一会儿可以变成房子，一会儿可以变成

继承 = 遗传继承是面向对象最基本的特征，如果一个语言没有继承机制，就谈不上真正的面向对象的语言。 继承本身很好理解，和我们日常生活中的“继承”概念基本一样：子承父业！所以，你可以看到面向对象的编程语言里面，有了“父类”、“子类”的概念。 但是我个人认为“继承”这个说法并不确切，一般我们理解“继承”，都是理解为继承产业、继承财产，例如李泽钜继承李嘉诚的事业。但在面向对象的领域里

完成了用例之后，需求分析的工作基本上已经完成，接下来我们需要趁热打铁，完成另外一个事情：提取功能点！ 有了用例之后，提取功能可以说是一个水到渠成的事情，基本上只是一个文字工作，我们只需要将用例中那些需要系统完成的事情——更简单的说：是动词——提取出来，就成为了系统的功能。 以前面的POS机为例，我们看看如何提取功能，如下粗体字即为提取的功能： 【用例名称】

抛开项目流程，让我们来谈谈“技术流程”吧！！谈到流程，很多人立刻就会想到熟悉的瀑布模型、螺旋模型、迭代开发、敏捷、RUP等一堆软件工程相关的软件开发流程，但对于大部分人来说，这些流程仅仅是项目管理上的概念，只有项目经理开例会时那红红绿绿的甘特图、燃尽图、路径图等，或者只有评估工作量和是否要加班的时候，我们才会意识到这些流程的存在。 通俗的讲，项目管理上的流程主要是用于指导项目经

封装的概念本身很好理解，意思就是把一堆东东装起来。 但要想真正理解封装，这样还远远不够。第一个问题是：我们要封装什么？这个问题很好回答，封装当然是封装不想让别人知道或者看到的东东了。例如：你的身家。。。。。。漂亮MM的年龄。。。。。。富二代的女朋友数。。。。。明星是否整过容。。。。。。你是如何赚到100万的（想想什么样

对于大部分人来说，可能并没有机会进行需求分析，因为在大部分的公司里面，需求分析都是有很多工作经验的资深人员，或者是对系统很熟悉的老的开发人员。 所以，很多人都会对需求分析有一种景仰的心态，认为既然做需求的人要求这么高，那么需求分析一定很复杂、很难、很高级了。而且很多需求分析人员动不动就会教训“你要站在客户的角度”、“你要全面的分析”等，然后再抛出几个需求建模之类的玩意吓吓你。。。。。。