java与模式学习

一、类图
1.在UML类图中，类名是正体字，说明是具体类；类名是斜体字说明是抽象类。
类图共有五层，第一是类名层（不能省略），其他都可省略，依次为属性层（定义变量）、方法层、性质层（由内部变量、赋值函数、取值函数组成即get、set）、实现父类和接口。
方法前有+表示是public，-表示是private,如果前面是#，表示是protected。方法下如果有一道下划线，表示这是一个静态方法。

2. 类图中的关系
一般化Generalization)关系: 表示类与类之间的继承关系。extends、implements,用一个三角箭头表示。
关联(Association):一个类知道另一个类的属性和方法。是通过实例变量实现的。可以表现为n..m的关系。注意类之间是处于同一层次的。用一个实线箭头表示。
聚合(Aggregation):是强的关联关系，聚合是整体和个体之间的关系。也通过实例变量来实现，类之间是不平等的层次上。用空的菱形表示。也可以称为委派关系。
合成(Composition):比聚合还强的关联关系，整体要负责部分的生命周期。合成关系不能共享。用黑色实体菱形表示。
依赖(Dependency):是单向的，用虚箭头表示。被依赖类里没有依赖类的属性，是通过参量方式传入的。
实现(Realize): 显示类与接口、包与接口、和用例与用例实现之间的关系。用虚线加一个三角箭头表示。

二、对象的可维护性和可复用性
1.开－闭原则(OCP): 一个软件实体应当对扩展开放，对修改关闭。
Software entities should be open for extension, but closed for modification.
2.实现：不允许更改系统的抽象层，而允许扩展系统的实现层。所以问题的关键就是在于抽象化和对可变性的封装。抽象即提取所有的具体类必须提供的方法的特征作为系统设计的抽象层；而可变性不应当散落在代码各处，而应封装到一个对象里。

三、具体java语言的实现
1.接口:
从asp转过来，以前一直对java的接口的不是很理解，这里看到一个比喻很形象。

在家中，可以很容易将微波炉从一个电源插座上拔下，然后将手提电脑插上去。对于插座来说，这些电器都是可插入的构件，之所以可插入，因为他们都具有与插座相匹配的插头。

所谓接口，实际就相当于电源插座。接口是实现构件的可插入性的关键。
java接口(Interface),是一些方法的集合。接口只有方法的特征，而没有实现，还可以定义public的常量。
对接口的实现问题上，有另外一个比喻很好：

接口常常代表一个角色(ROLE)，它包装与该角色相关的操作和属性，而实现这个接口的类便是扮演这个角色的演员。一个角色可以由不同的演员来演，而不同的演员除了扮演一个共同角色外，不需要由任何其他共同之处。

2.为何使用接口
一句话：没有接口，可插入性就没有保证。
一个类等级结构中的任何一个类都可以实现一个接口，这个接口会影像到此类的所有子类，但不会影像此类的任何超类。此类要实现接口的所有方法，而其子类可以自动继承或选择重载这些方法。
最诱人一点：

如前面关联所讲，一个对象需要完成一项任务，需要知道其他的对象，调用其他对象的方法。如果这个关联不是针对一个具体类，而是针对一个接口的，那么任何实现这个接口的类都可以满足要求。这样一来，可以动态的将这个关联从一个具体类转换到另一个具体类，只要这些类都实现了某个接口。同样，如果一个对象需要调用其他对象的方法，而这个调用来自一个接口。那么任何实现这个接口的具体类都可以被当前对象所调用,而当前对象到底调用哪一个具体类的实例完全可以动态的决定。

所以理想情况下，一个具体的java类应当只实现java接口和抽象java类中声明过的方法，而不应该给出多余的方法。

3.抽象类
抽象类不能实例化，它提供一个类型的部分实现。抽象类可以有实例变量，以及一个或多个的构造子。抽象类可以同时由抽象方法和具体方法。这种其实是模板方法模式的体现。
 抽象类的用途：抽象类通常代表一个抽象的概念，它提供一个继承的出发点。具体类不是用了继承的。抽象类应当拥有尽可能多的共同代码，一个对象从超类继承来的代码，在不使用时不会造成对资源的浪费；抽象类应当拥有尽可能少的数据，数据的移动方向时从抽象类到具体类，一个对象的数据不论是否使用都会占用资源。
一般而言，一个商业类型不会与一个工具类型有直接继承关系。商业类型封装商业
逻辑，不会是工具类型的一种。但可以商业类型到工具类型的一个委派。

4.接口和抽象类的对比：
抽象类可以提供某些方法的具体实现，而接口不可以。如果一个抽象类加入一个新的具体的方法，那么所有的子类型直接都可以得到这个新的具体方法，而接口不行。
抽象类的局限是一个类只能从最多一个超类继承。但接口可以实现任意多继承。
示例：

如上图，Account并不依赖具体类，而依赖两个抽象类AccountType和AccountStatus。AccountType抽象类有两个具体类，储蓄帐户和支票帐户，如果有新的具体类添加到系统中，比如引进一个新型的帐户，MoneyMarket类型，Account不需要改变，只需要增加一个具体类MoneyMarket.

四、几个原则：
1.里氏代换原则(LSP):
一个实体如果使用的是一个基类的话，那么一定适用于其子类，而且根本不能察觉出其区别。比如，假设有两个类，一个是base类，一个是Derived类，Derived类是base类的子类，那么method(Base b)如果成立，则method(d)也一定成立。
以上假设反过来代换不成立。
2.依赖倒转原则(DIP):
基本原则：要依赖抽象，不要依赖具体。客户端依赖于抽象的耦合。
一个java程序需要引用一个对象，如果这个对象有一个抽象类型的话，应当使用这个抽象类型作为变量的静态类型。如，list是一个java接口。按照依赖原则，Vector employee = new Vector();是不符合这个原则的，应该改为List employee = new Vector();.这个好处是如果决定将Vector类型转换成ArreyList是，只需要改动很少，List employee = new ArrayList();,这样程序有很好的灵活性。
3.接口隔离原则(ISP):
即使用多个专门的接口比使用一个总接口要好。打比喻说一个接口应该只扮演一个角色，如果有多种角色，那就应该分为多个接口来实现。