首页 > 代码库 > 扩展功能==继承?

扩展功能==继承?

              学过面向对象的我们都知道。通过继承:可以重用和扩展已经被彻底測试过的代码,且无需改动之。但就像策略模式中所讲到的,继承会禁锢类的方法。那么假设要扩展功能。我们还是必须使用继承吗?

              答案当然是否定的,由于设计模式中为我们提供了一个非常好的模式--装饰模式:动态地将责任附加到对象上。这里所谓的动态能够简单理解为灵活。那么不使用继承。又要怎样帮助我们达到目的呢?以下一起来看。

             先来看一个样例,我们去咖啡店买咖啡,光咖啡类型就有不同的选择:综合、深焙、低咖啡因、浓缩。但喝咖啡可没这么简单,它还须要添加对应的配料来满足顾客口味需求:牛奶、豆浆、摩卡、奶泡。如今咖啡店要添加一些新口味和类型,那么原先使用继承的系统将不再适用,一旦添加的类型和种类增多以下的这张图就变成一坨了吧:

        技术分享

         那么使用装饰模式应该是什么样的呢?

          技术分享

            像上面这幅图显示的这样。我们将详细的咖啡类型和配料都作为一个类的子类,通过类型和配料的自由组合实现功能的同一时候实现代码的复用性,提高后期的可维护性。其代码例如以下: 

1.抽象类

<span style="font-size:18px;">package 巴兹咖啡;
//这是一个抽象类。
public abstract class Beverage {
	String description ="Unknown Beverage";
	
	public String getDescription (){
		//获取咖啡调配方法
		return description;
	}
	
	public abstract double cost();
}
</span>


2.详细组件

public abstract class CondimentDecorator extends Beverage {
	public abstract String getDescription();
}

public class DarkRoast extends Beverage {

	public DarkRoast() {
		description ="DarkRoast Coffee";   
	}
	
	public double cost(){
		return .99;
	}

}
</span>
public class Espresso extends Beverage {
	
	public Espresso ()
	{
		description ="Espresso";
	}
	
	public double cost(){
		return 1.99;
	}
}
public class HouseBlend extends Beverage {
	public HouseBlend(){
		description ="House Blend Coffee";
	}
	
	public double cost(){
		return .89;
	}
}
</span>

          其它几个类和上面列举的类似。大家能够动手实现。终于会实现以下的效果:

         技术分享

            假设店内有需求。要实现杯型大小来进行收费,那么我们能够在CondimentDecorator中加入中杯、小杯、大杯三个类。抽象类中加入方法:getSize()对杯型进行获取,然后通过杯型、咖啡类型和配料的不同搭配来实现灵活收费。这样一来也就实现了动态的加入的同一时候也达到了解耦的效用。岂不是一举两得?

总结:

 1.装饰模式中使用组合和托付在系统执行时对系统动态的添加功能。而该模式也就意味着我们要创建一堆的装饰者类,而它们又恰好是用来装饰组件的,比方:Mocha、Whip等四个配料都是用来装饰HouseBlend、 DarkRoast这 些咖啡类型的。

2.我们能够使用一个或者多个装饰者包装一个组件:调配出一个中杯的。增加牛奶、摩卡等的低咖啡因咖啡。

3.装饰者会导致设计中出现很多小对象。假设过度使用,程序依然会变得复杂。

也就是说,我们不能将咖啡的类型和配料的种类无限的扩张。否则系统会由于过多的咖啡种类和配料而执行缓慢甚至瘫痪。凡事遵循一度的问题,东西再好吃也不能撑死,模式再好用也不能拖死系统。

          

所以说。在一定程度上,装饰者模式还是非常棒的呢。

            最后祝大家软考顺利,考试加油,let‘s  go !!

技术分享

        

       

扩展功能==继承?