临沂做网站费用,wordpress抢救,网站优化建设兰州,佛山微信网站建设多少钱#x1f4e2; 声明#xff1a; #x1f344; 大家好#xff0c;我是风筝 #x1f30d; 作者主页#xff1a;【古时的风筝CSDN主页】。 ⚠️ 本文目的为个人学习记录及知识分享。如果有什么不正确、不严谨的地方请及时指正#xff0c;不胜感激。 直达博主#xff1a;「… 声明 大家好我是风筝 作者主页【古时的风筝CSDN主页】。 ⚠️ 本文目的为个人学习记录及知识分享。如果有什么不正确、不严谨的地方请及时指正不胜感激。 直达博主「古时的风筝」 。搜索或点击扫码 ———————————————— 假设系统中有一个接口这个接口已经被10个实现类实现了突然有一天新的需求来了其中5个实现类需要实现同一个方法。然后你就在接口中添加了这个方法的定义想着一切都很完美。
当你在接口和其中5个实现类中加完这个方法后一编译。不妙啊另外那 5 个实现类报错了没实现新加的这个方法。要知道接口中的方法定义必须要在实现类中实现才行缺一个都编译不过。
这时候你耳边突然响起了开发之初的老前辈跟你说的话“这几个实现以后可能差距越来越大接口中可能会加方法注意留口子”。 现在咋整
假设之前的接口是这样的只有吃饭和喝水两个方法。
public interface IUser {/*** 吃饭啊*/void eat();/*** 喝水啊*/void drink();
}现在有 5 个实现类厉害了要加一个 play() 方法。
既然情况已经这样了现在应该怎么处理。
破罐子破摔吧走你
不管什么接口不接口的了哪个实现类要加就直接在那个实现类里加吧接口还保持之前的样子不动仍然只有吃饭和喝水两个方法play 方法就直接加到 5 个实现类中。
public class UserOne implements IUser{Overridepublic void eat() {System.out.println(吃饭);}Overridepublic void drink() {System.out.println(喝水);}public void play() {System.out.println(玩儿);}
}虽然可以实现但是完全背离了当初设计接口的初衷本来是照着五星级酒店盖的结果盖了一层之后上面的变茅草屋了。
从此以后接口是接口实现类是实现类基本上也就没什么关系了。灵活性倒是出来了以后想在哪个实现类加方法就直接加了。 再加一个接口行不
还是有点儿追求吧我新加一个接口行不行。之前的接口不动新建一个接口这个接口除了包含之前的两个方法外再把 play 方法加进去。
这样一来把需要实现 play 方法的单独在弄一个接口出来。就像下面这样 IUser是之前的接口。IUserExtend接口是新加的加入了 play() 方法需要实现 play() 方法的实现类改成实现新的IUserExtend接口只改几个实现关系改动不是很大嘛心满意足了。 但是好景不长啊过了几天又要加新方法了假设是上图的 UserOne和 UserNine要增加方法怎么办呢 假如上天再给我一次机会
假如上天再给我一次重来的机会我会对自己说“别瞎搞看看设计模式吧”。
适配器模式
适配器模式可以通过创建一个适配器类该适配器类实现接口并提供默认实现然后已有的实现类可以继承适配器类而不是直接实现接口。这样已有的实现类不需要修改而只需要在需要覆盖新方法的实现类中实现新方法。 不是要加个 play() 方法吗没问题直接在接口里加上。
public interface IUser {void eat();void drink();void play();
} 适配器类很重要它是一个中间适配层是一个抽象类。之前不是实现类直接 implements 接口类吗而现在适配器类 implements 接口类而实现类 extends 适配器类。
在适配器类可以给每个方法一个默认实现当然也可以什么都不干。
public abstract class UserAdapter implements IUser {Overridepublic void eat() {// 默认实现}Overridepublic void drink() {// 默认实现}Overridepublic void play() {// 默认实现}
}public class UserNine extends UserAdapter {Overridepublic void eat() {System.out.println(吃饭);}Overridepublic void drink() {System.out.println(喝水);}Overridepublic void play() {System.out.println(玩儿);}
}public class UserTen extends UserAdapter {Overridepublic void eat() {System.out.println(吃饭);}Overridepublic void drink() {System.out.println(喝水);}
}调用方式
IUser userNine new UserNine();
userNine.eat();
userNine.drink();
userNine.play();IUser userTen new UserTen();
userTen.eat();
userTen.drink();这样一来接口中随意加方法然后在在适配器类中添加对应方法的默认实现最后在需要实现新方法的实现类中加入对应的个性化实现就好了。
策略模式
策略模式允许根据不同的策略来执行不同的行为。在这种情况下可以将新方法定义为策略接口然后为每个需要实现新方法的实现类提供不同的策略。
把接口改成抽象类这里面 eat() 和 drink() 方法不变可以什么都不做实现类里想怎么自定义都可以。
而 play() 这个方法是后来加入的所以我们重点关注 play() 方法策略模式里的策略就用在 play() 方法上。
public abstract class AbstractUser {IPlayStrategy playStrategy;public void setPlayStrategy(IPlayStrategy playStrategy){this.playStrategy playStrategy;}public void play(){playStrategy.play();}public void eat() {// 默认实现}public void drink() {// 默认实现}
}IPlayStrategy是策略接口策略模式是针对行为的模式玩儿是一种行为当然了你可以把之后要添加的方法都当做行为来处理。
我们定一个「玩儿」这个行为的策略接口之后不管你玩儿什么怎么玩儿都可以实现这个 IPlayStrategy接口。
public interface IPlayStrategy {void play();
}然后现在做两个实现类实现两种玩儿法。
第一个玩儿游戏的实现
public class PlayGameStrategy implements IPlayStrategy{Overridepublic void play() {System.out.println(玩游戏);}
}第二个玩儿足球的实现
public class PlayFootballStrategy implements IPlayStrategy{Overridepublic void play() {System.out.println(玩儿足球);}
}然后定义 AbstractUser的子类
public class UserOne extends AbstractUser{Overridepublic void eat() {//自定义实现}Overridepublic void drink() {//自定义实现}
}调用方式
public static void main(String[] args) {AbstractUser userOne new UserOne();// 玩儿游戏userOne.setPlayStrategy(new PlayGameStrategy());userOne.play();// 玩儿足球userOne.setPlayStrategy(new PlayFootballStrategy());userOne.play();
}整体的类关系图大概是这个样子: 最后
通过适配器模式和策略模式我们即可以保证具体的实现类实现共同的接口或继承共同的基类同时又能在新增功能方法的时候尽可能的保证设计的清晰。不像之前那种破罐子破摔的方式接口和实现类几乎脱离了关系每个实现类各玩儿各的。
您的点赞、收藏、评论都是我前进路上的动力
推荐阅读
➿ 剑走偏锋无头浏览器是什么神奇的家伙
➿ 新项目决定用 JDK 17了
➿ 5000字10张图完全掌握 MySQL 事务隔离级别
