【Head First】类图关系与代码对应(Java)
亲!
最看Head First设计模式、深感比大话设计模式更深、当初感觉策略与工厂结合特别不爽、因为还要改工厂、这次直接用接口选择、不修改、只扩展、呼呼、听说有好多人看这个有难度、其实我看也有很多迷糊的、也许是因为与大话设角度的问题吧、这次从新总结了类图之间的关系、重在代码、是什么的知识就不讲了。
关系强度从弱到强:
依赖关系(Dependency)---关联关系(Association)---聚合(Aggregation)---组合(Composition)---泛化(Generalization)
关系与代码对应:
继承
<span style="font-size:18px;">Public class Father{ //父亲类 } Public class son extends Father{ //儿子类继承父亲类 }</span>
实现接口
<span style="font-size:18px;">//买手机接口 Public interface BuyIPhone{ //买手机方法 Public void Buy(); } Public class Father{ //父亲类实现买手机方法 Public void Buy(){ //买手机代码略 }; }</span>
依赖
<span style="font-size:18px;">Public class IPhone{ //具体方法略 } //1、方法中声明或new Public class chen{ Public void Usephone(){ IPhone chenphone;//声明 IPhone chenphone = new IPhone();//New了一个手机的对象 }; } //2、当做方法的参数 Public class chen{ Public void Usephone(IPhone chenphone){ //实现略 }; }</span>
关联(有一个)
这个与关联蛮像的、但是这个声明是在类里的、而不是某个方法。
<span style="font-size:18px;">//依赖的声明和NEW是在方法外面的 Public class chen{ IPhone chenphone;//声明 IPhone chenphone = new IPhone();//New了一个手机的对象 Public void Usephone(){ }; }</span>
关联和依赖的区别:
- 从类的属性是否增加的角度看:
发生依赖关系的两个类都不会增加属性。其中的一个类作为另一个类的方法的参数或者返回值,或者是某个方法的变量而已。
发生关联关系的两个类,其中的一个类成为另一个类的属性,而属性是一种更为紧密的耦合,更为长久的持有关系。
- 从关系的生命周期来看:
依赖关系是仅当类的方法被调用时而产生,伴随着方法的结束而结束了。
关联关系是当类实例化的时候即产生,当类销毁的时候,关系结束。相比依赖讲,关联关系的生存期更长。
组合
B类构造时候、在自身类中NEW了一个A对象、B对象释放、A对象随之释放。
<span style="font-size:18px;">Publicclass Bird{ <span style="white-space:pre"> </span>Public Wing wing; <span style="white-space:pre"> </span>Public void Bird(){ <span style="white-space:pre"> </span>wing =new Wing; <span style="white-space:pre"> </span>}; }</span>
鸟没了翅膀也没法活。
聚合
B类构造时从类外传进一个对象A、B对象释放、A对象还在外面没释放。
<span style="font-size:18px;">Publicclass BirdGroup{ <span style="white-space:pre"> </span>Public Bird bird; <span style="white-space:pre"> </span>Public void BirdGroup(Bird b){ <span style="white-space:pre"> </span>bird =b; <span style="white-space:pre"> </span>}; }</span>
鸟群没了、鸟照样活。
设计原则
页数 |
原则 |
9 |
找出变化的、把他们独立,不和不需要变化的混在一起 |
11 |
针对接口编程、而不针对实现编程。 |
23 |
多用组合、少用继承 |
53 |
为交互对象之间的松耦合努力 |
86 |
开放扩展、关闭修改 |
139 |
依赖抽象、不依赖具体 |
265 |
最少知道原则:只和密友谈话 |
339 |
一个类应该只有一个引起变化的原因 |
总结:
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。