设计模式之美——多组合少继承

Posted iblade

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了设计模式之美——多组合少继承相关的知识,希望对你有一定的参考价值。

组合优于继承,多用组合少用继承。

继承举例

假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念,定义为一个抽象类 AbstractBird。所有更细分的鸟,比如麻雀、鸽子、乌鸦等,都继承这个抽象类。

我们知道,大部分鸟都会飞,那我们可不可以在 AbstractBird 抽象类中,定义一个 fly() 方法呢?答案是否定的。鸵鸟就不会飞。鸵鸟继承具有 fly() 方法的父类,那鸵鸟就具有“飞”这样的行为,不合常规。

当然在鸵鸟这个子类中重写(override)fly() 方法,让它抛出 UnSupportedMethodException 异常虽然可以解决问题,但不够优美。因为除了鸵鸟之外,不会飞的鸟还有很多,比如企鹅。对于这些不会飞的鸟来说,我们都需要重写 fly() 方法,抛出异常。

这样的设计,一方面,徒增了编码的工作量;另一方面,也违背了最小知识原则(Least Knowledge Principle,也叫最少知识原则或者迪米特法则),暴露不该暴露的接口给外部,增加了类使用过程中被误用的概率。

那就“飞/不会飞”分类吧:
但如果我们还关注“鸟会不会叫”,那这个时候,我们又该如何设计类之间的继承关系呢?是否会飞?是否会叫?两个行为搭配起来会产生四种情况:会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫。如果我们继续沿用刚才的设计思路,那就需要再定义四个抽象类。
如果我们还需要考虑“是否会下蛋”这样一个行为,那估计就要组合爆炸了。类的继承层次会越来越深、继承关系会越来越复杂。而这种层次很深、很复杂的继承关系,一方面,会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性,必须阅读父类的代码、父类的父类的代码……一直追溯到最顶层父类的代码。另一方面,这也破坏了类的封装特性,将父类的实现细节暴露给了子类。子类的实现依赖父类的实现,两者高度耦合,一旦父类代码修改,就会影响所有子类的逻辑。

“层深”和“复杂”影响代码可读性和可维护性,怎么办?

实际上,我们可以利用组合(composition)、接口、委托(delegation)三个技术手段,一块儿来解决刚刚继承存在的问题。

接口表示具有某种行为特性。针对“会飞”这样一个行为特性,我们可以定义一个 Flyable 接口,只让会飞的鸟去实现这个接口。对于会叫、会下蛋这些行为特性,我们可以类似地定义 Tweetable 接口、EggLayable 接口。我们将这个设计思路翻译成 Java 代码的话,就是下面这个样子:


public interface Flyable 
  void fly();

public interface Tweetable 
  void tweet();

public interface EggLayable 
  void layEgg();

public class Ostrich implements Tweetable, EggLayable //鸵鸟
  //... 省略其他属性和方法...
  @Override
  public void tweet()  //... 
  @Override
  public void layEgg()  //... 

public class Sparrow impelents Flyable, Tweetable, EggLayable //麻雀
  //... 省略其他属性和方法...
  @Override
  public void fly()  //... 
  @Override
  public void tweet()  //... 
  @Override
  public void layEgg()  //... 

不过,我们知道,接口只声明方法,不定义实现。也就是说,每个会下蛋的鸟都要实现一遍 layEgg() 方法,并且实现逻辑是一样的,这就会导致代码重复的问题。那这个问题又该如何解决呢?

我们可以针对三个接口再定义三个实现类,它们分别是:实现了 fly() 方法的 FlyAbility 类、实现了 tweet() 方法的 TweetAbility 类、实现了 layEgg() 方法的 EggLayAbility 类。然后,通过组合和委托技术来消除代码重复。具体的代码实现如下所示:


public interface Flyable 
  void fly()
public class FlyAbility implements Flyable 
  @Override
  public void fly()  //... 

//省略Tweetable/TweetAbility/EggLayable/EggLayAbility

public class Ostrich implements Tweetable, EggLayable //鸵鸟
  private TweetAbility tweetAbility = new TweetAbility(); //组合
  private EggLayAbility eggLayAbility = new EggLayAbility(); //组合
  //... 省略其他属性和方法...
  @Override
  public void tweet() 
    tweetAbility.tweet(); // 委托
  
  @Override
  public void layEgg() 
    eggLayAbility.layEgg(); // 委托
  

我们知道继承主要有三个作用:表示 is-a 关系,支持多态特性,代码复用。而这三个作用都可以通过其他技术手段来达成。比如 is-a 关系,我们可以通过组合和接口的 has-a 关系来替代;多态特性我们可以利用接口来实现;代码复用我们可以通过组合和委托来实现。所以,从理论上讲,通过组合、接口、委托三个技术手段,我们完全可以替换掉继承,在项目中不用或者少用继承关系,特别是一些复杂的继承关系。


public class Url 
  //...省略属性和方法


public class Crawler 
  private Url url; // 组合
  public Crawler() 
    this.url = new Url();
  
  //...


public class PageAnalyzer 
  private Url url; // 组合
  public PageAnalyzer() 
    this.url = new Url();
  
  //..

还有一些特殊的场景要求我们必须使用继承。如果你不能改变一个函数的入参类型,而入参又非接口,为了支持多态,只能采用继承来实现。比如下面这样一段代码,其中 FeignClient 是一个外部类,我们没有权限去修改这部分代码,但是我们希望能重写这个类在运行时执行的 encode() 函数。这个时候,我们只能采用继承来实现了。


public class FeignClient  // Feign Client框架代码
  //...省略其他代码...
  public void encode(String url)  //... 


public void demofunction(FeignClient feignClient) 
  //...
  feignClient.encode(url);
  //...


public class CustomizedFeignClient extends FeignClient 
  @Override
  public void encode(String url)  //...重写encode的实现...


// 调用
FeignClient client = new CustomizedFeignClient();
demofunction(client);


我们在基于 MVC 架构开发 Web 应用的时候,经常会在数据库层定义 Entity,在 Service 业务层定义 BO(Business Object),在 Controller 接口层定义 VO(View Object)。大部分情况下,Entity、BO、VO 三者之间的代码有很大重复,但又不完全相同。我们该如何处理 Entity、BO、VO 代码重复的问题呢?

答:Entity, Bo, Vo三者之间,显然并不存在 is-a关系,首先排除使用继承。

其次三者间也并非是严格的has-a关系,half measure之一是考虑使用组合(composition) + 委托(delegation)的方式解决代码重复的问题,但并不是我心中的最佳答案.

我的答案是不解决三者间的代码重复问题。Value Class就只是Value Class, 代码重复并不是业务上的代码重复,那就让它重复吧.

这三者其实就是三个领域的东西,不能因为属性的现实意义相同就混为一谈,海水里的鱼和鱼缸里的鱼虽然都是鱼,但是用法是不一样的,哈哈

以上是关于设计模式之美——多组合少继承的主要内容,如果未能解决你的问题,请参考以下文章

步步为营-04-一个通过接口实现多态的经典例子

为何说要多用组合少用继承?如何决定该用组合还是继承?

设计模式之美——封装,继承,多态的意义

设计模式之美-结构型-适配器模式

设计模式----设计遵循法则及(简单工厂,工厂方法,单例模式)(2018/10/29)

设计模式之美(c++)-笔记-51-适配器模式