城市的生活成本(模板方法)

public abstract class Boy {
	//收入
	private double wages;
	
	/**
	 * 模板方法模式：定义一个操作中算法的骨架，而将一些步骤延迟到子类中。
	 * 模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
	 */
	//生活在这座城市的成本（具体算法）
	public void live_in_theCity(){
		System.out.println(
				"房贷六千吃穿用度两千五，" +
				"冉冉上幼儿园一千五，" +
				"人情往来六百，" +
				"交通费五百八，" +
				"物业管理三四百，" +
				"手机电话费两百五，" +
				"还有煤气水电费两百"+ "给2奶的钱"+give_money_to_Lover());//特定步骤
		
	}
	public double give_money_to_Lover(){
	 
		return 0;
		
	}
	
	public double getWages() {
		return wages;
	}
	public void setWages(double wages) {
		this.wages = wages;
	}
	
}

 子类不需要从写live_in_theCity业务类，因为子类只需要在业务方法中有很小的改动，

 

public class BeautifulGirl extends Boy {
	
	public double give_money_to_Lover() {
		 
	 return this.getWages()*0.2;
	}

}

 

 

public class SensibleGirl extends Boy {
	
	public double give_money_to_Lover() {
		 
		 return this.getWages()*0.8;
		}

}

 

 

通过比较我们能发现事物的本质，也能通过比较才会出现有记忆点

看下面泛化不够彻底的实现

public abstract class Boy {
	//收入
	private double wages;
	
	 
	//生活在这座城市的成本（具体算法）
	public void live_in_theCity(){
		System.out.println(
				"房贷六千吃穿用度两千五，" +
				"冉冉上幼儿园一千五，" +
				"人情往来六百，" +
				"交通费五百八，" +
				"物业管理三四百，" +
				"手机电话费两百五，" +
				"还有煤气水电费两百钱"
		
	}
	 
	public double getWages() {
		return wages;
	}
	public void setWages(double wages) {
		this.wages = wages;
	}
	
}

 

下面是子类重写了整个业务方法，如果女友很多的话，每次的继承都要重复很多重复的代码，这是坏味道，

我们需要将它提取出来让boy更像一个模板

 

public class LooksMediocreGirl extends Boy{

	@Override
	public void live_in_theCity() {
		 
		super.live_in_theCity();

                                 System.out.println("包我要付"+getWages()*0.3);
		
		
	}
	
	

}

 

 

如果我有一百个妞怎么办了，难道要我一个个这么实现吗？需要摆脱这些纠缠

 

加个rate

public class  Girl extends Boy {
	double rate ;
	public double give_money_to_Lover() {
		 
		 return this.getWages()*this.getRate();
		}
	
	public double getRate() {
		return rate;
	}
	public void setRate(double rate) {
		this.rate = rate;
	}
   
}

 

这样的话界面上直接加小妞要的粒度rate就OK了，不管你new多少都没问题。

 

和策略比的话，策略的各子类的业务方法变法比较大，模板方法各子类的业务方法变化相对很小