java应用架构设计模块化模式与OSGI读书笔记
看博客中的设计模式总结，和看java应用架构设计模块化模式与OSGI书的感想：
六大规则（zuoxiaolong8810（左潇龙）总结的非常好了）
1.单一职责原则（六大规则中的小萝莉，人见人爱）：描述的意思是每个类都只负责单一的功能，切不可太多，并且一个类应当尽量的把一个功能做到极致。
单一职责原则是内聚。内聚表示类完成单一功能的程度。内聚的类更易理解，同时还易维护。
2.迪米特原则（六大原则中最害羞的姑娘，不太爱和陌生人说话）：也称最小知道原则，即一个类应该尽量不要知道其他类太多的东西，不要和陌生的类有太多接触。
3.里氏替换原则（六大原则中最文静的姑娘，但却不太招人喜欢）：这个原则表达的意思是一个子类应该可以替换掉父类并且可以正常工作。
4.接口隔离原则（六大原则当中最挑三拣四的挑剔女，胸部极小）：也称接口最小化原则，强调的是一个接口拥有的行为应该尽可能的小。
在java应用架构设计模块化模式与OSGI中原则：
众多的接口要优于单一的，通用性的接口。
5.依赖倒置原则（六大原则中最小鸟依人的姑娘，对抽象的东西非常依赖）：这个原则描述的是高层模块不该依赖于低层模块，二者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
6.开-闭原则（六大原则中绝对的大姐大，另外五姐妹心甘情愿臣服）：最后一个原则，一句话，对修改关闭，对扩展开放。
例：
一个金融机构，我们要允许顾客使用不同类型的账户存款。
Account类与AccountType抽象类产生了关联。换句话说，Account类与AccountType
继承体系的抽象层产生了耦合。因为，Savings和Checking都继承自AccountType类，
所以通过动态绑定的方式，就能引用AccountType类的地方替换这些类的实例。
Account类：
publicclass Account {
private AccountType _act;
public Account(String act){
Class c;
try {
c = Class.forName(act);
this._act=(AccountType) c.newInstance();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
publicvoid deposit(int amt){
this._act.deposit(amt);
}
}
AccountType接口：
publicinterface AccountType {
publicvoid deposit(int amt);
}
Checking类：
书中居然写的类是
publicclass Checking extends AccountType{
实在是不明白作者到底有没有亲自写这段代码.
publicclass Checking implements AccountType{
@Override
publicvoid deposit(int amt) {
// TODO Auto-generated method stub
System.out.println("Amount deposited in "+
"checking account:"+ amt);
}
}
Savings类：
书中居然写的类是
publicclass Savings extends AccountType{
和上面一样，费解啊。
publicclass Savings implements AccountType{
@Override
publicvoid deposit(int amt) {
// TODO Auto-generated method stub
System.out.println("Amount deposited in "+
"Savings account:"+ amt);
}
}
因为Account并没有直接与具体的Savings或Checking类耦合，所以我们不用修改Account就可以扩展AccountType类，创建新的实现如MoneyMarket.
因此，OCP的一个原则就是将类之间的耦合降低到抽象级别。
我们不是在两个具体的类之间建立关联，而是在具体类和抽象类之间建立关联，在java中也就是在具体类和接口之间。
7.在java应用架构设计模块化模式与OSGI中没有迪米特原则相应的是组合重用原则
这一原则应该是包设计原则中一种
优先选择对象的多态组合而不是继承。
组合重用原则能够让我们避免犯一个灾难性的错误，这个错误会导致面向对象的系统遭受灭顶之灾，那就是：使用继承作为主要的重用机制。
导致错误的使用合成，聚合与继承的一个常见的原因是错误的把“Has-a”关系当作“Is-a”关系。
“Has-a”代表一个类时另外一个类的角色。
“Is-a”代表一个类时另外一个类的一种。
举个例子：
把“人”当成一个类，然后把“雇员”，“经理”，“学生”当成是“人”的子类。这个的错误在于把“角色”的等级结构和“人”的等级结构混淆了。“雇员”，“经理”，“学生”是一个人的角色，一个人可以同时拥有上述角色。若按照继承来设计，一个人是雇员的话，那就不可能是学生了。所以创建一个类图：
父类人下面有非洲人，和亚洲人，两个子类，那么角色下载有经理，学生，雇员三个角色。
无论是什么样的人都可以是经理，学生，雇员角色，所以只需要人员类和角色类变成关联关系而不是继承关系。
java应用架构设计模块化模式与OSGI读起来很吃力啊，还到处是错误，感觉白花了50大洋啊。