将策略的上下文的构造函数换用简单工厂模式的话就将业务对象封装起来了,客户端就只要了解Boy这个对象就ok了 ,不需要自己去声明接口DreamGir的业务对象l。
//上下文
public class Boy {
private DreamGirl girl;
Boy(DreamGirl girl) {
this.girl = girl;
}
public void want_to_eat() {
girl.prepare_food();
}
public DreamGirl getGirl() {
return girl;
}
public void setGirl(DreamGirl girl) {
this.girl = girl;
}
public static void main(String[]args){
DreamGirl 韩媛媛 = new BeautifulGirl();
Boy ysen = new Boy(韩媛媛);
ysen.want_to_eat();
}
}
//男孩心中抽象的梦中女孩
public abstract class DreamGirl {
//准备食物方法
public abstract void prepare_food();
}
public class LivelyGirl extends DreamGirl{
public void prepare_food() {
System.out.println("老公喜欢我做的酸菜鱼");
}
}
//相貌平平的女孩 呵呵
public class LooksMediocreGirl extends DreamGirl{
public void prepare_food() {
System.out.println("老公喜欢我做的糖醋里脊");
}
}
//一位漂亮的女孩呵呵
public class BeautifulGirl extends DreamGirl {
public void prepare_food() {
System.out.println("老公喜欢我做的土豆炖肉嘿嘿");
}
}
//一位理智的女孩 呵呵
public class SensibleGirl extends DreamGirl{
public void prepare_food() {
System.out.println("老公喜欢我做的鱼香肉丝");
}
}
老公喜欢我做的土豆炖肉嘿嘿
介于部分朋友觉得内容不太露骨,(老鸟略过) 感觉不出策略思想到底是用来解决样的什么问题。
首先策略思想它强调的是用组合来封装原有的动态行为方法。
变化的行为用组合 has a
不变的行为用继承 is a
下面我来改下Boy类
//上下文
public class Boy {
private DreamGirl girl;
Boy(DreamGirl girl) {
this.girl = girl;
}
public void want_to_eat() {
girl.prepare_food();
}//参照上面的Boy类这个行为方法很明显是变化的,所以我们需要抽象这个方法,就是通过美女接口以及具体的业务实现类(不同的girl)
public void prepare_food() {
//System.out.println("老公喜欢我做的鱼香肉丝");
}
public DreamGirl getGirl() {
return girl;
}
public void setGirl(DreamGirl girl) {
this.girl = girl;
}
}
很明显我的 prepare_food() 行为是变化的,我这里用的只能是组合,声明接口DreamGirl是为了可以实现不同的业务类型(不同的女孩),现在的情况是DreamGirl依赖于Boy 但是却实现了业务的变化,我们这里完全可以通过spring 来降低耦合