iLeichun

关于代码重复最著名的单词是Kent Beck的Once And Only Once，也就是说软件操作的任何一个片断--不管是一个算法，一个常量集合，用于阅读的文档或者其他东西--应当只出现一次。
软件重复出现至少会导致以下问题：
a 其中的一个版本会过期
b 代码的责任会四处散开，导致代码难以理解
c 当你修改代码时，需要重复修改很多地方，一不小心就会遗漏
d 你不能很好地进行性能优化

重复代码的产生由各种各样的原因，经常看到程序员把几行或一整段代码从这里复制到这里，然后少加修改，就变成了一份新的代码。这里的原因是程序员可以通过极少的努力就完成代码重用，但是我们可以来看看DavidHooker提出的7个软件开发原则:

1.第一原则：存在的理由(Pattern: TheReason)
一个软件系统存在的理由就是：为它的用户提供价值。你所有的决定都取决于这一点。在指定一个系统需求，在写下一段系统功能，在决定硬件平台和开发过程之前，问你自己一个问题，“这样做会为系统增加价值吗？“，如果答案是”yes”，做。如果是”No”,不做。这个原则是其他原则的原则。

2．第二原则（能简单就简单，愚蠢！）KISS (Pattern: KeepItSimple)
软件设计不是一个轻描淡写的过程。在做任何一个设计时，你必须考虑很多因素。所有设计应当尽可能简单，但是不要再比这简单了。这样产生的系统才是可以理解和容易维护的。这并不是说很多由意义的特性，因为这种简单性也要被抛弃。确实很多更优雅的设计往往更简单，但简单并不意味着“quick and dirty."。事实上，简单是通过许多思考和一次一次的反复修改才达到的。这些努力的汇报就是更容易维护，代码错误更少。 （看看是否违反）

3．第三原则 ：保持远见(Pattern: MaintainTheVision)
清晰的远见是一个软件项目成功的基础。. 没有这样的远见，项目开发最后就变成天天为一个不好的设计做补丁。Brooks说过：
概念的完整性是系统设计中最重要的问题。
Stroustrup 也说：
有一个干净的内部结构识构建一个可理解、可辨识、可维护
、可测试系统的基础。
Booch则总结道：
只有当你对系统的体系由一个清晰的感觉，才可能去发现通用的抽象和机制。开发这种通用性最终导致系统更简单，因此更小，更可靠
如果你不断地复制、粘贴、修改代码，最终你将陷入一个大泥潭(the Big Mud),你永远不可能对系统有一个清晰的认识。

4.第四原则：你制造的，别人会消费 (Pattern: WhatYouProduceTheyConsume)
软件系统不是在真空中使用的。其他人会使用、维护、文档你的系统。这依赖于对你系统的理解。所以，你设计、实现的东西应当能够让别人理解。要记住，你写的代码并非只给计算机看，你要时时记住，代码还要给人看。(Kent Beck)
如果到处泛滥似是而非的代码，别人如何能够辨别这些代码的相似和不同，如何去理解这些代码之间具有何种关系。
 

5．第五原则：对将来开放( Pattern BuildForTodayDesignForTomorrow)
一个成功的软件有很长的生命期。你必须能够使得软件能够适应这样和那样的变化。所以，一开始就不要软件设计到死角上去。请总是问一下自己“如果这样，那么。。？“这个问题，你要考虑到各种各样的可能性，而不光光是图省事。复制，粘贴一下即可。

6．第六原则：为重用做好计划
软件模式是重用计划的一种。不断重复的代码显然不是这样的计划。
(See CommentsOnSix)

7．第七原则：思考！
在采取任何动作之前首先做一个清晰、完整的考虑，这样才能产生更好的结果。如果你考虑了，但还是产生错误的结果，那么这种努力也是值得的。在你学习或研究类似的问题时，更容易理解和掌握。

本节和大家学习一下UML类图依赖关系和其他关系区别，UML类图中的关系分为四种，这里向大家一一介绍，相信通过本节的介绍你对UML类图依赖关系以及其他几种关系有明确的认识。

UML类图依赖关系和其他关系区别

UML类图中的关系分为四种：UML类图依赖关系、泛化关系、关联关系、实现关系；关联关系又可以细化为聚合和组合。

1. 泛化（Generalization)

泛化是父类和子类之间的关系，子类继承父类的所有结构和行为。在子类中可以增加新的结构和行为，也可以覆写父类的行为。
                          

2. 依赖（Dependencies）

UML类图依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用，两个元素之间的一种关系，其中一个元素（服务者）的变化将影响另一个元素（客户），或向它（客户）提供所需信息。它是一种组成不同模型关系的简便方法。依赖表示两个或多个模型元素之间语义上的关系。它只将模型元素本身连接起来而不需要用一组实例来表达它的意思。它表示了这样一种情形，提供者的某些变化会要求或指示依赖关系中客户的变化。

根据这个定义，关联和泛化都是依赖关系，但是它们有更特别的语义，故它们有自己的名字和详细的语义。我们通常用依赖这个词来指其他的关系。依赖用一个从客户指向提供者的虚箭头表示，用一个构造型的关键字来区分它的种类，通常情况下，UML类图依赖关系体现在某个类的方法使用另一个类作为参数 。
       

3. 关联（Association）

关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。关联有两元关系和多元关系。两元关系是指一种一对一的关系，多元关系是一对多或多对一的关系。一般用实线连接有关联的同一个类或不同的两个类。当你想要表示结构化关系时使用关联，如果几个类元的实例之间有联系，那么这几个类元之间的语义关系即关联。关联描述了系统中对象或实例之间的离散连接。

关联将一个含有两个或多个有序表的类元，在允许复制的情况下连接起来。最普通的关联是一对类元之间的二元关联。关联的实例之一是链。每个链由一组对象（一个有序列表）构成，每个对象来自于相应的类。二元链包含一对对象。关联带有系统中各个对象之间关系的信息。当系统执行时，对象之间的连接被建立和销毁。关联关系是整个系统中使用的“胶粘剂”，如果没有它，那么只剩下不能一起工作的孤立的类。在关联中如果同一个类出现不止一次，那么一个单独的对象就可以与自己关联。如果同一个类在一个关联中出现两次，那么两个实例就不必是同一个对象，通常的情况都如此。二元关联用一条连接两个类的连线表示。

聚集表示部分与整体关系的关联，它用端点带有空菱形的线段表示，空菱形与聚集类相连接。组成是更强形式的关联，整体有管理部分的特有的职责，它用一个实菱形物附在组成端表示。每个表示部分的类与表示整体的类之间有单独的关联，但是为了方便起见，连线结合在一起，现在整组关联就像一棵树。

关联关系是通过类的成员变量 来实现的 。下面看一下UML类图依赖关系和聚合的联系。                   

3.1 聚合（Aggregation）

聚合是一种特殊的关联。它描述了“has a”关系，表示整体对象拥有部分对象。

来源：(http://blog.sina.com.cn/s/blog_4c4d6e740100aixn.html) - UML类图中的关系_匆匆路人_新浪博客
关联关系和聚合关系来语法上是没办法区分的，从语义 上才能更好的区分两者的区别。聚合是较强的关联关系，强调的是整体与部分 之间的关系。

与关联关系一样，聚合关系也是通过类的成员变量 来实现的。               

3.2 组合（Composition）

组合是聚合的一种形式，它具有更强的拥有关系，强调整体与部分的生命周期 是一致的。整体负责部分的生命周期的管理。如果整体被销毁，部分也必须跟着一起被销毁，如果所有者被复制，部分也必须一起被复制。

与关联关系一样，组合关系也是通过类的成员变量 来实现的。  

4. 实现（Realization）

实现关系指定两个实体之间的一个合约。换言之，一个实体定义一个 合约 ，而另一个实体保证履行该 合约 。

    最近与同事聊天，从软件质量保证的方法论谈论到了技术管理，那技术管理的内涵到底是什么？在此通过这篇文章做一个小小的总结和适当的外延。

     纬度之一就是项目管理，其中包括项目计划、风险管理、预算管理等。对于基层技术管理者，更多涉及的内容是工作量评估、项目计划、项目进度管理等等。这一纬度的可见性很强，一项做不好就很容易让上级“紧张”，因此每一项内容都有专门的培训课程。

     另一个纬度则是团队管理，在现在很多技术性企业中，采用的都是人力资源管理进直线的方式，即技术管理者还要承担一定的人力资源方面的管理工作，比如绩效管理、职业发展规划等，当然这些内容给人的感觉更多的是“很虚”。由于这种特性，造成真正意义上关注团队管理的情形相对要少得多，与之相对应的培训课程也更少。

     相信在不少企业，将技术管理更多地理解为项目管理，在管理活动中似乎只有风险、计划和时间表，而忽视了培养团队。在图2中存在两个点和一条射线，其中点A代表团队A对于技术管理在两个纬度所采取的权重，同理，B点则代表B团队。从图中可以直观地看出，A团队更加侧重于团队管理，而B团队则更加侧重于项目管理。另外，图中的射线代表如果团队权重是分布在这条线上或附近，则说明这个团队在技术管理中很好地掌控了团队管理与项目管理的平衡。

     一个团队的技术管理，其两个纬度的权重在图2中的分布或许不是一成不变的，应当根据不同的时期调整其侧重点，但是，无论如何团队管理应当是技术管理的核心内容，或者更进一步地说，提高团队技能是技术管理的核心课程。

     团队管理不能只是出去吃吃饭做一做team building什么的，更为重要的是要提高团队的技能，且是实实在在地提高团队的技能。项目管理中的很多问题，都可以通过提高团队的技能从而缓解，乃至根治。举一个例子，为什么我们对于风险管理（项目管理中的内容）那么的执着？那是因为团队的能力不足以应对所面临的挑战！当然，作者并不是要说团队的技能上去了就不需要风险管理，而是指当技能增强了以后，对于风险的掌握自然就强了，而对于风险管理的要求就会有所弱化。团队技能上不去，项目管理工作只会是越做越累，且只是工作在问题的表面。

     提高团队的技能是一个很不轻松的话题，因为它在理但却很难操作。但无论如何，技术管理者首先应当具备这种意识，因为只有意识先行才会有所行动。现实中，存在不少现象，技术管理者说“我的老板才不管团队技能的培养呢，他只关心他自己，因为团队能力的提高并不是他的首要职责，他只要求我将产品按计划做出就行了。老板不管，那我也就更管不了，也没有给我时间去做啊。”对于这种借口存在以下几个问题：

     1）产品按计划完成意味着项目成功了，但它并不意味着产品成功。一个技能不行的团队是能进行产品开发，也能做到项目成功，但一定做不到产品成功。可能一发布产品，就“全员求火”了。

     2）如果每一级管理者都采用这样的借口，那最终的结果就是没有人真正关心团队技能的培养。一个企业为什么需要那么多的（技术）管理者？只是为了让更多的人去找借口？显然不是。在所有从上到下的管理者中，一定需要有一层去关注团队技能的培养，那只能是基层技术管理者，即通常我们所说的组长或team lead。因为团队技能不足，第一个受害者就是团队自身，而基层管理者身在其中。有的基层管理者，他的工作主要就是schedule以及来自上级的指令，对于团队技能的提高似乎与已无关，更谈不上对团队的激励了。这种对团队技能忽视的现象其实是对自身利益将被损害所表现出来的一种麻木。技术管理者能否将团队技能逐渐地提高，或许是评价其管理能力出色与平庸的关键指标。

     3）培养团队不是有时间就能解决问题，而首先需要有意识。时间总会是有的，因为项目总是要做的。有了意识以后，同样是做一件工作，所采用的策略将完全不同，而团队所学得的知识也很有可能更多。

     技术管理者除了需要有提高团队技能的意识，更要注意方法论的运用，打造适合团队自身的方法论也显得尤为必要。另外，承担一定的责任和适当的风险有助于为工程师们提高技能创造空间。

本文出自 “李云” 博客，请务必保留此出处http://yunli.blog.51cto.com/831344/331586

    对于软件行业的从业人员，不论是管理者还是工程师，对于软件设计的重要性都应当有允分的认识，只有这样才有可能在团队中构建真正有意义的愿景。是的，具备出色软件设计能力的工程师少之又少，但这并不表明它不重要。相反，这种人的工作效能很有可能是普通工程师的百倍。

     在切入主题之前先要了解“上”与“下”的含意是什么，这需要从图1中找答案。图中，应用层在最上面，其下依次是框架、平台、库和操作系统层，因此“上”是指靠近应用层，而“下”则是指靠近操作系统层。

   面向对象大家都很熟悉，可是基于对象就不一定了。两个听起来好象是同一回事，而事实上它们却千差万别。基于对象是指：我们采用对象这一封装技术，将数据和操作捆绑在一起，但是并没有合理的使用多态、继承等面向对象的技术进行设计。其中的“没有合理使用”这一修饰非常的重要，可以说它道出了面向对象和基于对象的本质区别。

    虽然，听起来面向对象我们很是熟悉，但就我的观察，很多以前从事C程序开发的人，当他（她）采用面向对象的编程语言（如C++）进行开发时，写出来的程序却是基于对象的。更为通俗的说，采用面向对象的语言编写面向过程的程序！

    要掌握面向对象技术不是一件容易的事，其要求我们对于所有的编程事务从“对象”的角度来考虑，是一种全新的思考问题的方法。我想错用最近面试过的一位工程师的话来说明什么是面向对象开发，他是这么说的“现实世界是什么，那么程序当中就应当是什么”，我觉得这句话概括得非常的好。

    从我的学习经验来看，一开始其实我并不明白为什么要用对象来封装，记得刚从C转向C++时，只是觉得C++是另一种形式的“C”，那时并没有深刻的领悟到C++语言中所蕴涵的面向对象的强大开发能力。后来，因为工作的需要，需要对来自Microsoft MSDN中的一个Drawcli例程进行一定的扩展，这个程序你现在从MSDN光盘中还能找到，如果你想真的理解面向对象，Drawcli是一个非常好的开端。如果你懂了Drawcli的设计思想，你一定会对面象对象有一个感性认识。

    当然，做了Drawcli以后，我不认为我的面向对象的开发能力就一下子上去了，而是在平时的开发过程中要去模仿。模仿着模仿着，在一次一个应程序的开发时，我记得当时我对于一个在多种情况下的复杂管理问题很是苦恼，后来突然想到了从其中抽象出一个类来做管理，那一刻所有的困惑全都没有了。之前之所以复杂是因为采用面向过程的思考方式去解决，而当我换成面向对象的方式时，其实是很简单的问题。在那一刻，我真的领悟到了面向对象设计的好处，也是从模糊的理解到真正的理解的一个转折点！从那以后，我觉得自己能做到对于软件设计“现实世界是什么，在程序中就应当是什么”。
 

本文出自 “李云” 博客，请务必保留此出处http://yunli.blog.51cto.com/831344/184846