徐州网络推广服务,长安seo排名优化培训,网站新闻图片尺寸,wordpress 文章找不到定义 策略#xff08;Strategy#xff09;模式定义了算法族#xff0c;分别封装起来#xff0c;让它们之间可以互相替换 #xff0c;此模式让算法的变化独立于使用算法的客户。 案例#xff1a;模拟鸭子应用 一开始 新需求#xff1a;模拟程序需要会飞的鸭子 在父类新…定义 策略Strategy模式定义了算法族分别封装起来让它们之间可以互相替换 此模式让算法的变化独立于使用算法的客户。 案例模拟鸭子应用 一开始 新需求模拟程序需要会飞的鸭子 在父类新添加fly()方法。 这样做的弊端并非Duck所有的子类都会飞如橡皮鸭。 当涉及维护时为了复用reuse目的而使用继承结局并不完美。 一种补救的方法把橡皮鸭类中的fly()方法覆盖掉。 新麻烦加入诱饵鸭DecoyDuck类它是假鸭不会飞也不会叫。 利用继承来提供Duck的行为这会导致下列缺点 代码在多个子类中重复。运行时的行为不容易改变。难以得知所有鸭子的全部行为。改变会牵一发动全身造成其他鸭子不想要的改变。 每当有新的鸭子子类出现就要被迫检查并可能需要覆盖fly()和quark()这简直是无穷尽的恶梦。 一种改进可以把fly()取出来放进一个Flyable接口中。这么一来只有会飞的鸭子才实现此接口。同样的方式 也可以用来设计一个Quackable接口因为不是所有的鸭子都会叫。 虽然Flyable与Quackable可以解决一部分的问题不会再有会飞的橡皮鸭 但是却造成代码无法复用这只能算是从一个恶梦跳进另一个恶梦。甚至在会飞的鸭子中飞行的动作可能还有多种变化… 这意味着无论何时你需要修改某个行为你必须得往下追踪并修改每一个定义此行为的类一不小心可能造成新的错误。 MyNoteJava8的default关键可在接口类具有实现代码。 美好的愿景如果能有一种建立软件的方法好让我们需要改变软件时可以在对既有的代码影响最小的情况下轻易达到花较少时间重做代码而多让程序去做更酷的事。该有多好… 软件开发的一个不变真理变化永存 不管当初软件设计得多好一阵子之后总是需要成长与改变否则软件就会死亡。 驱动改变的因素很多如 顾客或用户需要别的东西或者想要新功能。公司决定采用别的数据库产品也从另一家厂商买了数据这造成数据格式不兼容。 设计原则变定分离 找出应用中可能需要变化之处把它们独立出来 不要和那些不需要变化的代码混在一起。 把会变化的部分取出并封装起来好让其他部分不会受到影响。代码变化之后出其不意的部分变得很少系统变得更有弹性。 MyNote把精力集中在变化上。 换句话说如果每次新的需求一来都会变化到某方面的代码那么你就可以确定这部分的代码需要被抽出来和其他闻风不动的代码有所区隔。 下面是这个原则的另一种思考方式把会变化的部分取出并封装起来以便以后可以轻易地扩充此部分而不影响不需要变化的其他部分。 这样的概念很简单几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让系统中的某部分改变不会影响其他部分。 模拟鸭子程序中的变定分离 Duck类内的fly()和quack()会随着鸭子的不同而改变。 为了要把这两个行为从Duck类中分开 我们将把它们自Duck类中取出建立一组新类代表每个行为。 设计鸭子两个行为 我们希望一切能有弹性我们还想能够指定行为到鸭子的实例比方说想要产生绿头鸭实例并指定特定类型的飞行行为给它。 干脆顺便让鸭子的行为可以动态地改变好了。换句话说我们应该在鸭子类中包含设定行为的方法就可以在运行时动态地改变绿头鸭的飞行行为。 设计原则针对接口编程 而不是针对实现编程。 我们利用接口代表每个行为比方说FlyBehavior与QuackBehavior而行为的每个实现都必须实现这些接口之一。所以这次鸭子类不会负责实现这接口反而是由其他类专门实现FlyBehavior与QuackBehavior这其他类就称为行为类。由行为类实现行为接口而不是由Duck类实现行为接口。 这样的作法迥异于以往以前的作法是 行为是继承Duck超类的具体实现而来 继承某个接口并由子类自行实现而来。 这两种作法都是依赖于实现我们被实现绑得死死的没办法更改行为除非写更多代码。 在我们的新设计中鸭子的子类将使用接口FlyBehavior与QuackBehavior所表示的行为所以实际的实现不会被绑死在鸭子的子类中。换句话说特定的实现代码位于实现FlyBehavior与QuakcBehavior的特定类中。 设计原则针对接口编程 而不是针对实现编程 针对接口编程真正的意思是针对超类型supertype编程。 这里所谓的接口有多个含意接口是 一个概念一种Java的interface构造。 你可以在不涉及Java interface的情况下针对接口编程关键就在多态。 利用多态程序可以针对超类型编程执行时会根据实际状况执行到真正的行为不会被绑死在超类型的行为上。 针对超类型编程这句话可以更明确地说成变量的声明类型应该是超类型通常是一个抽象类或者是一个接口如此只要是具体实现此超类型的类所产生的对象都可以指定给这个变量;这也意味着声明类时不用理会以后执行时的真正对象类型 看看下面这个简单的多态例子假设有一个抽象类Animal有两个具体的实现Dog与Cat继承Animal。 针对实现编程作法如下: Dog d new Dog(); d.bark(); 声明变量d为Dog类型是Animal的具体实现会造成我们必须针对实现编码。 但是针对接口/超类型编程作法会如同下面 Animal animal new Dog(); animal.makeSound();我们知道该对象是狗 但是我们现在利用animal进行多态的调用。 更棒的是子类型实例化的动作不再需要在代码中硬编码例如new Dog()而是在运行时才指定具体实现的对象。 a getAnimal(); a.makeSound();我们不知道实际的子类型是什么我们只关心它知道如何正确地进行makeSound()的动作就够了。 MyNote一开始编码时写具体实现没有错中途有需求变化就积极重构吧 实现鸭子的行为 我们有两个接口FlyBehavior和QuackBehavior还有它们对应的类负责实现具体的行为 这样的设计可以让飞行和呱呱叫的动作被其他的对象复用因为这些行为已经与鸭子类无关了。 而我们可以新增一些行为 不会影响到既有的行为类 也不会影响有使用到飞行行为的鸭子类。 这么一来有了继承的复用好处却没有继承所带来的包袱。(MyNote顺得哥情亦不失嫂意) 整合鸭子的行为 关键在于鸭子现在会将飞行和呱呱叫的动作委托delegate别人处理而不是使用定义在自己类或子类内的方法。 然后实现performQuack() performFly()类似 public class Duck {QuackBehavior quackBehavior;// 还有更多public void performQuack() {//不亲自处理呱呱叫行为而是委托给quackBehavior对象。quackBehavior.quack();} }Duck的子类在构造器中赋值行为变量 public class MallardDuck extends Duck {public MallardDuck() {quackBehavior new Quack();flyBehavior new FlyWithWings();}public void display() {System.out.println(“I’m a real Mallard duck”);} }放码过来 鸭子抽象类 public abstract class Duck {FlyBehavior flyBehavior;QuackBehavior quackBehavior;public Duck() {}public void setFlyBehavior(FlyBehavior fb) {flyBehavior fb;}public void setQuackBehavior(QuackBehavior qb) {quackBehavior qb;}abstract void display();public void performFly() {flyBehavior.fly();}public void performQuack() {quackBehavior.quack();}public void swim() {System.out.println(All ducks float, even decoys!);} }诱骗鸭 public class DecoyDuck extends Duck {public DecoyDuck() {setFlyBehavior(new FlyNoWay());setQuackBehavior(new MuteQuack());}public void display() {System.out.println(Im a duck Decoy);} }绿头鸭 public class MallardDuck extends Duck {public MallardDuck() {quackBehavior new Quack();flyBehavior new FlyWithWings();}public void display() {System.out.println(Im a real Mallard duck);} }红头鸭 public class RedHeadDuck extends Duck {public RedHeadDuck() {flyBehavior new FlyWithWings();quackBehavior new Quack();}public void display() {System.out.println(Im a real Red Headed duck);} }橡皮鸭 public class RubberDuck extends Duck {public RubberDuck() {flyBehavior new FlyNoWay();quackBehavior new Squeak(); // quackBehavior () - System.out.println(Squeak);}public RubberDuck(FlyBehavior flyBehavior, QuackBehavior quackBehavior) {this.flyBehavior flyBehavior;this.quackBehavior quackBehavior; }public void display() {System.out.println(Im a rubber duckie);} }飞行行为接口 public interface FlyBehavior {public void fly(); }不能飞行行为类 public class FlyNoWay implements FlyBehavior {public void fly() {System.out.println(I cant fly);} }能飞行行为类 public class FlyWithWings implements FlyBehavior {public void fly() {System.out.println(Im flying!!);} }叫声行为接口 public interface QuackBehavior {public void quack(); }不叫行为类 public class MuteQuack implements QuackBehavior {public void quack() {System.out.println( Silence );} }呱呱叫行为类 public class Quack implements QuackBehavior {public void quack() {System.out.println(Quack);} }吱吱叫行为类 public class Squeak implements QuackBehavior {public void quack() {System.out.println(Squeak);} }运行测试类 public class MiniDuckSimulator {public static void main(String[] args) {Duck mallard new MallardDuck();mallard.performQuack();mallard.performFly();System.out.println(---);Duck model new RedHeadDuck();model.performFly();//改变飞行行为model.setFlyBehavior(new FlyNoWay());model.performFly();} }运行结果 Im Quack Im flying!! --- Im flying!! I cant fly本例子类与接口全家福 设计原则多用组合少用继承 根据本例使用组合建立系统具有很大的弹性不仅可将算法族封装成类 更可以在运行时动态地改变行为只要组合的行为对象符合正确的接口标准即可。 参考资料 Head First 设计模式