组合模式
1.基本介绍

组合模式（Composite Pattern）,又叫部分整体模式，它创建了对象组的树形结构，将对象组合成树状结构以表示“整体-部分”的层次关系
组合模式依据树形结构来组合对象，用来表示部分以及整体层次，属于结构性模式
组合模式使得用户对单个对象和组合对象的访问具有一致性（组合模式能让用户以一致的方式处理个别对象以及组合对象）

2.原理类图


Component：这是组合中对象的声明接口或者抽象类，在适当情况下，实现所有类共有的接口默认行为，用于访问和管理Component的子部件
Leaf：在组合中表示叶子节点，叶子节点没有子节点
Composite：非叶子节点，用于存储子部件，在Component接口或抽象类中实现字部件的相关操作

3.案例

院校结构展示

实现类图


University属于最高一级，Department属于叶子节点

代码实现
抽象类的设计
public abstract class OrganizationComponent {
	private String name;
	private String des;
	//默认实现，因为叶子节点不需要实现
	protected void add(OrganizationComponent organizationComponent) {
		throw new UnsupportedOperationException();
	}
	protected void remove(OrganizationComponent organizationComponent) {
		throw new UnsupportedOperationException();
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	public String getDes() {
		return des;
	}
	public void setDes(String des) {
		this.des = des;
	}
	public OrganizationComponent(String name, String des) {
		super();
		this.name = name;
		this.des = des;
	}
	//子类实现
	public abstract void print()
}


Univresity类
public class University extends OrganizationComponent{
	//管理子节点
	List<OrganizationComponent> organizations = new ArrayList<>();
	
	public University(String name, String des) {
		super(name, des);
    }
	@Override
	public void print() {
		System.out.println("============"+getName()+"==============");
		for(OrganizationComponent organizationComponent : organizations) {
			organizationComponent.print();
		}
	}
	@Override
	protected void add(OrganizationComponent organizationComponent) {
		organizations.add(organizationComponent);
	}
	@Override
	protected void remove(OrganizationComponent organizationComponent) {
		organizations.remove(organizationComponent);
	}
}

其余非叶子节点
public class College extends OrganizationComponent{
	List<OrganizationComponent> organizations = new ArrayList<>();
	public College(String name, String des) {
		super(name, des);
		// TODO Auto-generated constructor stub
	}
	@Override
	public void print() {
		System.out.println("============"+getName()+"==============");
		for(OrganizationComponent organizationComponent : organizations) {
			organizationComponent.print();
		}
	}
	@Override
	protected void add(OrganizationComponent organizationComponent) {
		//按需求扩展
		organizations.add(organizationComponent);
	}
	@Override
	protected void remove(OrganizationComponent organizationComponent) {
		organizations.remove(organizationComponent);
	}
}

叶子节点
public class Department extends OrganizationComponent{
	public Department(String name, String des) {
		super(name, des);
		// TODO Auto-generated constructor stub
	}
	@Override
	public void print() {
		System.out.println(getName());
	}
}


构建树型结构以及调用
public class Client {
	public static void main(String[] args) {
		University university = new University("清华大学","国内最好的大学之一");
		
		College college1 = new College("计算机学院", "计算机学院");
		College college2 = new College("信息工程学院", "信息工程学院");
		
		college1.add(new Department("软件工程", "软件工程"));
		college1.add(new Department("网络工程", "网络工程"));
		college1.add(new Department("计算机科学与技术", "计算机科学与技术"));
		
		college2.add(new Department("通信工程", "通信工程"));
		
		university.add(college1);
		university.add(college2);
		
		university.print();
	}
}

4.JDK中Map的组合模式
1.使用类图分析


可以看到Map和AbstractMap是属于我们说的组合模式中的Component对象，声明方法的接口或者抽象类
HashMap其子类，属于子节点的类，用于存储子部件
Node是HashMap的内部类，从源码可以发现他就是我们组合模式中讲述的Leaf节点，他只有get，set功能
如上大致可以看出这是一个组合模式，接下来我们用源码来看看

2.源码分析


先看到Map接口，可以看到定义的众多方法中有两个我们常用的方法，put()，putAll()，他将被实现
public interface Map<K,V> {
    ………………
	V put(K key, V value);
	void putAll(Map<? extends K, ? extends V> m);
    ………………
}



接着来到AbstractMap，它实现了Map接口，由于Map的实现类会有很多，所以jdk中使用这个抽象类来作为缓冲类，将一些方法默认实现，使得该接口更具有扩展性，如下它默认实现了put()和putAll()
public abstract class AbstractMap<K,V> implements Map<K,V> {
    ……………………
    //默认实现
    public V put(K key, V value) {
        throw new UnsupportedOperationException();
    }
    public void putAll(Map<? extends K, ? extends V> m) {
       for (Map.Entry<? extends K, ? extends V> e : m.entrySet())
            put(e.getKey(), e.getValue());
    }
    ……………………
}



然后我们来到最常用HashMap类中，可以看到它对接口和抽象类都进行了实现，发现了还有一个Node对象
public class HashMap<K,V> extends AbstractMap<K,V>
    implements Map<K,V>, Cloneable, Serializable {
    ……………………
    //来到put方法，看到这里进行了具体的实现
    public V put(K key, V value) {
        return putVal(hash(key), key, value, false, true);
    }
    //这里省略具体的操作，我们只关心设计模式，putAll也与put方法类似，就不讲述了，之后会再写一些关于java集合类的具体实现
    final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        //这里用到了一个Node对象，我们进入到Node对象中观察
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        ………………………………
    }
}



来到HashMap的内部类Node对象中，我们发现，他其实就是我们组合模式中所讲述的Leaf对象，它没有再组合任何的子节点，提供的也只有get方法和set方法
 static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        V value;
        Node<K,V> next;
        Node(int hash, K key, V value, Node<K,V> next) {
            this.hash = hash;
            this.key = key;
            this.value = value;
            this.next = next;
        }

        public final K getKey()        { return key; }
        public final V getValue()      { return value; }
        public final String toString() { return key + "=" + value; }

        public final int hashCode() {
            return Objects.hashCode(key) ^ Objects.hashCode(value);
        }

        public final V setValue(V newValue) {
            V oldValue = value;
            value = newValue;
            return oldValue;
        }

        public final boolean equals(Object o) {
            if (o == this)
                return true;
            if (o instanceof Map.Entry) {
                Map.Entry<?,?> e = (Map.Entry<?,?>)o;
                if (Objects.equals(key, e.getKey()) &&
                    Objects.equals(value, e.getValue()))
                    return true;
            }
            return false;
        }
    }




如上，我们可以清晰地看出来，Map中的HashMap是应用了组合模式来实现的


5.小结

简化客户端操作，客户端只需要面对一致的对象而不用考虑整体部分或者节点叶子的问题
具有较强的扩展性，我们组合对象时，只需要调整内部的层次关系
方便创建出复杂的层次关系，客户端不用理会组合里面的组成细节，容易添加节点或者叶子从而创建出复杂的树形结构
组合模式适用于遍历组织机构的场景以及需要复杂的树形结构
要求较高的抽象性，如果节点和叶子有很多差异的话，不适合使用组合模式

一.概念
E-R(Entity-Relationships)模式的构成成分是实体集、属性和联系集，其表示方法如下：
 （1） 实体集用矩形框表示，矩形框内写上实体名。

 （2） 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。

 （3） 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1—1、1—N或M—N。


关系模式（Relation Schema）是对关系的描述,它可以形式化地表示为：

R（U，D，dom，F）其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合。通常简记为：R(U)或R(A1，A2，…,An)其中R为关系名，U为属性名集合，A1，A2，…,An为各属性名。




二.E-R图转换为关系模型的转换规则
1)实体集转换为关系
–实体集对应于一个关系

–关系名：与实体集同名。

–属性：实体集的所有属性。

–主码：实体集的主码。



2) 联系转换为关系
联系转换成为关系模式。联系转换成为关系模式时，要根据联系方式的不同采用不同的转换方式

①1:1联系的转换方法
a) 将1:1联系转换为一个独立的关系：与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，且每个实体的码均是该关系的候选码。

b) 将1:1联系与某一端实体集所对应的关系合并，则需要在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体集的码。






第一步：联系形成的关系独立存在：
职工表（职工号，姓名，年龄）主码：职工号
产品表（产品号，产品名，价格）主码：产品号
负责（职工号，产品号）主码：职工号或产品号
合并方案1：“负责”与“职工”两关系合并：
    职工（职工号，姓名，年龄，产品号）
    产品（产品号，产品名，价格）
合并方案2：“负责”与“产品”两关系合并：
    职工（职工号，姓名，年龄）
    产品（产品号，产品名，价格，职工号）
 
② 1:n联系的转换方法
a)一种方法是将联系转换为一个独立的关系，其关系的属性由与该联系相连的各实体集的码以及联系本身的属性组成，而该关系的码为n端实体集的码；
 b)另一种方法是在n端实体集中增加新属性，新属性由联系对应的1端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。





步骤一：联系形成的关系独立存在。
仓库（仓库号，地点，面积）
 主码：仓库号
产品（产品号，产品名，价格）
 主码：产品号
仓储（仓库号，产品号，数量）主码：产品号
 
合并后方案：联系形成的关系与n端对象合并。
 仓库（仓库号，地点，面积）
  
③ m:n联系的转换方法
在向关系模型转换时，一个m:n联系转换为一个关系。转换方法为：与该联系相连的各实体集的码以及联系本身的属性均转换为关系的属性，新关系的码为两个相连实体码的组合（该码为多属性构成的组合码）。







该模型包含两个实体集（学生、课程）和一个m:n联系
该模型可转换为三个关系模式：
–学生（学号，姓名，性别，年龄）主码：学号
 
-课程（课程号，课程名，学分）主码：课程号
 
–选课（学号，课程号，成绩）主码：学号+课程号


二.总结

 
（1）一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
 
（2）一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
 
（3）一个m：n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体码的组合组成该关系的码，或码的一部分。
 
（4）三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
 
（5）具有相同码的关系模式可合并。

所谓范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别 
为不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立
在函数依赖基础上的。
函数依赖
定义：设有关系模式R(U)，X和Y是属性集U的子集，函数依赖是形为X→Y的一个命题，
对任意R中两个元组t和s，都有t[X]=s[X]蕴涵t[Y]=s[Y]，那么FD X→Y在关系模式R(U)中成
立。X→Y读作‘X函数决定Y’，或‘Y函数依赖于X’。
　　通俗的讲，如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确
定的，就称为Y函数依赖于X。
　　函数依赖应该是通过理解数据项和企业的规则来决定的，根据表的内容得出的函数
依赖可能是不正确的。
第一范式（1NF）
定义：果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模
式。
　　简单的说，每一个属性都是原子项，不可分割。
　　1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称
为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
第二范式（2NF）
定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第
二范式。
简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完
全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的
，而不能由主键的一部分来决定。
举个例子：
　　有股票日行情表的主键是股票代码和交易日期组成。非主属性中有收盘价和成交量
等，都是由主键，即股票代码和交易日期函数决定的，单独的股票代码或者交易日期都
不能函数决定这些非主属性。如果这个表中有非主属性股票简称，则股票简称是可以由
股票代码来函数决定的，这样股票简称这个非主属性就不是完全函数依赖于候选键，这
样的设计就不满足第二范式。
第三范式（3NF）
定义：如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选关键
字都不存在传递依赖，则称关系R是属于第三范式。
简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存
在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属
性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
举个例子：
在股票基本情况表中，主键是股票代码，有非主属性所属一级行业和所属二级行业。根
据业务规则，所属二级行业能够函数决定所属一级行业，这就表示存在这样一种关系：
股票代码函数决定所属二级行业，所属二级行业函数决定所属一级行业，这就形成了传
递依赖，这样的设计就不符合第三范式。
不过在实际运用中，为查询和使用的方便，有时也会违反第三范式。如上例，如果没有
所属一级行业的属性，需要查询所属一级行业的相关股票，需要查询时使用函数来从二
级行业中函数生成所属一级行业，使用性能上会受影响。所以通常会加上所属一级行业
的属性。
BC范式（BCNF）
BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包
括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。
本文出自 51CTO.COM技术博客

　　实现关系是用来描述接口和实现接口的类或者构建结构之间的关系，接口是操作的集合，而这些操作就用于规定类或者构建结构的一种服务。
　　在接口和类之间的实现关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。
　　UML示例图如下所示：

 
　　返回目录
转载于:https://www.cnblogs.com/eagle927183/p/3448993.html