文章转载至idv2.com的UML中的联系、聚合与组合的区别一文。

UML中的联系(association)、聚合(aggregation)和组合(composition)三个概念很相似，也很难理解。 今天看到这篇文章解释得很清楚，所以在这里转一下， 希望能对需要的人有所帮助。

联系

联系(association)表明某个对象可以向另一个对象通过某种方式发送消息。发送消息的方法可以通过指针成员变量， 也可以是方法参数、局部变量等等。例如：

class A
{
  private:
    B* itsB;
};

聚合

聚合(aggregation)是一种特殊的联系，它表明了“部分”到“整体”的关系，显著的特点就是不能包含循环的联系 （就是说，部分中不能包含整体）。如：

class Node
{
  private:
    vector<Node*> itsNodes;
};

上述代码只有当子节点不会成为父节点的父节点时（即，必须是树结构，不能是图结构），才能称之为聚合。

组合

组合(composition)跟聚合几乎相同，唯一的区别就是“部分”不能脱离“整体”单独存在，就是说， “部分”的生命期不能比“整体”还要长。例如：

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

相关链接

全面认识UML类图元素

别看UML工具有一大堆，好用而且免费的真是少之又少。StarUML 做的非常不错，所以推荐给大家使用。
用例图

ER图


类图

用UML工具画类图的时候，有时候会搞不清楚association, Aggregation,Gerneralization等名词的含义，下面这篇文章介绍很详细，具体的内容就不转载了。
http://developer.51cto.com/art/200601/17771.htm

另外UML中的联系、聚合与组合的区别 这篇文章着重解释了面向对象设计中联系、聚合、组合三者的含义。看完文章感觉要对三者加以区分还是要Case By Case

S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(Programming Priciple)的首字母缩写。

SRP	The Single Responsibility Principle	单一责任原则
OCP	The Open Closed Principle	开放封闭原则
LSP	The Liskov Substitution Principle	里氏替换原则
DIP	The Dependency Inversion Principle	依赖注入原则
ISP	The Interface Segregation Principle	接口分离原则

单一责任原则：
当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。

http://www.diybl.com/course/4_webprogram/jsp/jsp_js/20090304/157704.html

开放封闭原则
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。我对这个原则的理解还是很模糊，还需要在日后的工作、学习过程中慢慢体验:-)。


http://www.cnblogs.com/adam/archive/2008/04/18/1159280.html

里氏替换原则
当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系

http://lensping.blog.sohu.com/73111028.html


依赖注入原则
1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
2. 抽象不应该依赖于细节，细节应该依赖于抽象

http://hi.baidu.com/mickeycn/blog/item/e60900129241da56f819b884.html

接口分离原则
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
http://blog.csdn.net/xiaolu123456789/archive/2009/02/26/3941014.aspx

其他重要的面向对象设计原则
The Principles of OOD 这篇文章中介绍了其他一些面向对象设计的原则，有兴趣的同学可以进一步的学习。

总结
    这几条原则是非常基础而且重要的面向对象设计原则。正式由于这些原则的基础性，理解、融汇贯通这些原则需要不少的经验和知识的积累。希望能在日后的工作、学习过程中真正的掌握和运用这些原则。

   什么是Share nothing架构呢？以下内容翻译至wikipedia。
   Shared nothing架构（shared nothing architecture）是一 种分布式计算架构。这种架构中的每一个节点（ node）都是独立、自给的，而且整个系统中没有单点竞争。有些系统需要集中保存大量的状态信息——数据库、应用服务器或是其他类似的单点竞争系统。
   Shared Nothing在Web 应用开发中尤其受到欢迎，究其原因是这种方案提供的scalability。Google在这个方面做了很好的示范。 在一个纯Shared Nothing系统中，通过简单地增加一些廉价的计算机做为系统的节点却可以获取几乎无限的扩展。正是由于Shared Nothing架构中不存在单一瓶颈而降低系统运行速度。Google 称之为sharding。 Shared nothing系统通常需要将他的数据分布在多个节点的不同数据库中（不同的计算机处理不同的用户和查询）或者要求每个节点通过使用某些协调协议来保留它自己的应用程序数据备份 ，这通常被成为数据库Sharding。
   现在对一个有着多个独立的web节点却存在一个惟一的共享数据库这样的架构是否能被称之为 Shared nothing架构还是有很多争论的。一个状态型的应用（通常将状态保存到一个集中化的数据库中）要获得shared nothing架构就需要通过数据网格和分布式Cache。 但即便是这种架构，数据库依然是故障单点。
   参考资源包括：
   Share nothing理论在数据库设计和优化中的实践应用
   The Case for Shared Nothing Architecture