head设计模式 01

- 找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起

  换句话说,如果每次新的需求一来,都会使某方面的代码发生变化,那么你就可以确定,这部分代码需要被抽出来,和其他稳定的代码有区别。例如例子中的鸭子会飞 fly()方法,就需要独立出来。(把会变化的部分取出来并封装起来,以便以后可以轻易的改动或扩充此部分,而不影响不需要变化的其他部分)

image

- 针对接口编程,而不是针对实现编程

  委托(delegate)

  image

image

image

image

image

image

image

image

image

- 设计模式

image

- 例子及总结

  问题描述:

image 

现在想让鸭子能飞,该如何设计,如果只是在Duck这个类里增加飞的方法,不好,因为继承的子类里有的是玩具鸭子不能飞,如果是单独定义的接口,也不好,每个类实现接口的时候都需要每个都重新编码,飞的方法可能是固定的就那么1-2种,如果每个类都需要重新实现是不好的方法。那么怎么办呢?

将变化的方法抽象出来,比如飞和叫,然后再定义两个单独的类来实现该接口,那然后把这两个类作为自己的实例变量来实现。

- 例子分析

  目前我们有一套关于鸭子的游戏,有一个super class Duck, 如下图: 现在… boss说要鸭子可以飞。。。怎么办呢?(要求代码尽量少,并尽量满足oop), 我们知道,最好就是能够“一劳永逸”, 而且满足可复用,就是说,当再有新的方法添加时,比如鸭子可以”泡妞“,对别的不产生影响。

image

办法1: 在super class 中直接添加 fly()方法, 一劳永逸+可复用都满足,但是。。不满足逻辑,比如,水中的玩具鸭子,它能飞? 它是不可以飞的。即该子类不能继承这个方法。(此处你也可以在不能飞的子类继承时不实现fly()方法,但是,这不是结构在限制你,而是人为限制,人为的行为,就很有可能出现错误)

办法2: 定义一个fly接口,让可以飞的鸭子实现该接口,逻辑上过的去,该飞的可以飞,不该飞的不实现该接口就可以了。也可复用,但是不能做到一劳永逸,因为所有实现该接口的类必须完成该方法,而fly()方法是比较固定的,”煽动翅膀就可以飞了“。 要在每个实现该接口的子类里都定义一般”飞“,很多重复代码。

办法3:

UML: 类图

image

code:

Duck-Duck
原文地址:https://www.cnblogs.com/moveofgod/p/3056886.html