定义:
该模式定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的变化不会影响使用算法的客户。这种类型的设计模式属于行为型模式。
思路要点:
1.封装变化,面向接口编程
2.组合优于继承
举例:
玩家:小A;拥有角色和装备两个属性;
由于玩家可以转职,也可以穿戴不同的装备,那么就需要将玩家的角色和装备属性定义成接口,而不能定义成骑士类或者法师类。装备属性也不能简单的定义为长剑类或者法杖类。
角色(接口):骑士(实现类)法师(实现类)
武器(接口):长剑(实现类)法杖(实现类)
这样小A可以通过转职功能,选择转职为骑士或者法师。直接调用SetRole(IRole role)方法来设置玩家的职业。也可以通过穿戴不同的装备来进行输出。直接调用SetWeapon(IWeapon weapon)方法来穿戴不同的装备。
这样一来变化的部分(角色、武器)就被封装成两个接口,其具体的实现就跟玩家类无关了。玩家可以通过构造函数获取初始的角色和武器,也可以通过Set方法来改变角色和武器。这样就实现了封装变化,面向接口。
这种开发方式是通过组合来实现的,玩家和角色组合,玩家和武器组合。如果是通过继承的方式来开发,玩家类是无法通过同时继承两个不同的父类(角色类、武器类)来拥有角色和武器。如果通过依次继承(武器类继承角色类,玩家类再继承武器类)来实现,那么角色类和武器类里面需要把所有的角色和所有的武器都包含进去才行(因为不知道这个玩家再实际游戏里面会选择什么角色和武器)。但是这样又无法对某些角色限定某些武器(比如锤类武器法师无法穿戴但牧师就可以穿戴),或者后期添加某些角色或者某种武器的时候也非常的不方便。所以组合的方式比继承的方式更加的灵活