<>之前需求:
1:模拟鸭子项目
从项目”模拟鸭子游戏”开始。
鸭子都会叫,会游泳。有的鸭子是红头的,有的鸭子是绿头的。
分析:
从OO(面向对象,面向对象)的角度设计这个项目。
鸭子的父类:
抽象的
1 .都会嘎嘎叫
2 .抽象的外形(如:红头鸭、绿头鸭等)
3 .都会游泳
综上所述,我们得到鸭子父类:
公共抽象类鸭{
公共鸭(){};//1:鸭子都会叫
公共空间庸医(){
System.out.println(“~嘎嘎叫~”);
｝//2:抽象的外形
公共抽象空白显示();//3:鸭子都会游泳
公共空间游泳(){
system . out。println(“~ ~游泳~ ~”);
｝
｝
具体实现:
绿头鸭:
公开课GreenHeadDuck延伸鸭{
@Override
公共空间显示(){
system . out。println(“~ ~我GreenHeadDuck ~ ~嘎嘎”);
｝
}红头鸭:
公开课RedHeadQuck延伸鸭{
@Override
公共空间显示(){
system . out。println(“~ ~我读~ ~嘎嘎”);
｝
｝
新需求:
添加鸭子会飞的功能。
思考：
这个飞功能是放在父类中还是放到单个里面吗?
如果放到父类中,那么问题来了。并不是所有的鸭子都会飞。如果放到父类中,就成了所有鸭子都会飞了,这个是不对的。
所以,我们从这里就可以看出如果使用继承会导致的问题;
对类的局部改变,尤其是父类的局部改变,会影响其他部分。这种影响会有溢出的效应。
如果非要使用继承方法,也是可以的。我们在子类中覆盖父类的方法。
如在绿头鸭中将飞()方法覆盖类。
公共空间飞(){
system . out。println(“没有飞~ ~ ~ ~”);
｝
这个时候,又来新需求了了。需要一个石头鸭子。我们知道石头鸭子是不会飞,不会叫,不会游泳的
我们如果继承了鸭类。那么,就要不停的去填坑的。
所以,我们可以看出这种需求下如果还是用OO面向对象原则来的话,会出现:
父类挖的一个坑,每个子类都要来填坑。增加了工作量。其复杂度是O (N ^ 2)。这这种需求下,如果是这样设计的话就不是一个好的设计方式。
我们就要思考,需要新的设计模式,来应对项目的扩展性,降低项目的复杂度。
1)分析项目变化于不变化的部分,提取变化部分,抽象成接口+实现;
根据上面原则,我们在来看看鸭子游戏项目:
鸭子哪些功能会根据新需求变化呢?
如鸭子叫,飞行等等。
这个时候,我们可以设计如下接口:
鸭子飞行为的接口:
接口FlyBehaviro {
空飞();
｝
鸭子叫行为的接口:
接口Quackehavior {
无效的庸医();
｝
有了这两个接口之后,鸭子想飞实现飞行为的接口,鸭子想叫实现叫的接口。这样组合起来更方便。
这样做的好处:
新增行为简单了,行为类更好的被复用了,组合更方便的了,既有继承带来的复用好处,而其还没有挖的坑。
根据上面分析,我们重新设计鸭子模式:
1:将行为提取成抽象接口
FlyBeahavior
QuackBehavior
2:在父类鸭中,将各个抽象接口作为属性
@ data
公共抽象类鸭{
公共鸭(){}/* *
*飞行行为
*/FlyBehavior myFlyBehavior;
QuackBehavior myQuackBehavior;
公共空间飞(){
myFlyBehavior.fly ();
｝
公共空间庸医(){
myQuackBehavior.QuackBehavior ();
｝
公共抽象空白显示();
｝
3:在创建具体鸭子对象的时候,将行为实例化到构造器中。如下:
公开课GreenHeadDuck延伸鸭{
公共GreenHeadDuck () {
myFlyBehavior=new GoodFlyBehavior ();
myQuackBehavior=new GaGaQuackBehavior ();
｝
@Override
公共空间显示(){
system . out。println(“~ ~我GreenHeadDuck ~ ~嘎嘎”);
｝
｝
在测试方法中,父类实例化使用子类对象。如下:
鸭greenHeadDuck=new greenHeadDuck ();
greenHeadDuck.display ();
greenHeadDuck.fly ();
greenHeadDuck.quack ();
