网站建设的费用预算,designspiration官网,南京seo公司哪家,青海网站建设加q5299丶14602做词为什么不推荐使用继承#xff1f;
继承是面向对象的四大特性之一#xff0c;用来表示类之间的 is-a 关系#xff0c;可以解决代码复用的问题。虽然继承有诸多作用#xff0c;但继承层次过深、过复杂#xff0c;也会影响到代码的可维护性。所以#xff0c;对于是否应该在…为什么不推荐使用继承
继承是面向对象的四大特性之一用来表示类之间的 is-a 关系可以解决代码复用的问题。虽然继承有诸多作用但继承层次过深、过复杂也会影响到代码的可维护性。所以对于是否应该在项目中使用继承网上有很多争议。很多人觉得继承是一种反模式应该尽量少用甚至不用。为什么会有这样的争议我们通过一个例子来解释一下。
假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念定义为一个抽象类 AbstractBird。所有更细分的鸟比如麻雀、鸽子、乌鸦等都继承这个抽象类。
我们知道大部分鸟都会飞那我们可不可以在 AbstractBird 抽象类中定义一个 fly()方法呢答案是否定的。尽管大部分鸟都会飞但也有特例比如鸵鸟就不会飞。鸵鸟继承具有 fly() 方法的父类那鸵鸟就具有“飞”这样的行为这显然不符合我们对现实世界中事物的认识。当然你可能会说我在鸵鸟这个子类中重写overridefly() 方法让它抛出 UnSupportedMethodException 异常不就可以了吗具体的代码实现如下所示
public class AbstractBird {//... 省略其他属性和方法...public void fly() { //... }
}public class Ostrich extends AbstractBird { // 鸵鸟//... 省略其他属性和方法...public void fly() {throw new UnSupportedMethodException(I cant fly.);}
}
1234567891011
复制
这种设计思路虽然可以解决问题但不够优美。因为除了鸵鸟之外不会飞的鸟还有很多比如企鹅。对于这些不会飞的鸟来说我们都需要重写 fly() 方法抛出异常。这样的设计一方面徒增了编码的工作量另一方面也违背了我们之后要讲的最小知识原则Least Knowledge Principle也叫最少知识原则或者迪米特法则暴露不该暴露的接口给外部增加了类使用过程中被误用的概率。
你可能又会说那我们再通过 AbstractBird 类派生出两个更加细分的抽象类会飞的鸟类 AbstractFlyableBird 和不会飞的鸟类 AbstractUnFlyableBird让麻雀、乌鸦这些会飞的鸟都继承 AbstractFlyableBird让鸵鸟、企鹅这些不会飞的鸟都继承AbstractUnFlyableBird 类不就可以了吗具体的继承关系如下图所示 从图中我们可以看出继承关系变成了三层。不过整体上来讲目前的继承关系还比较简单层次比较浅也算是一种可以接受的设计思路。我们再继续加点难度。在刚刚这个场景中我们只关注“鸟会不会飞”但如果我们还关注“鸟会不会叫”那这个时候我们又该如何设计类之间的继承关系呢
是否会飞是否会叫两个行为搭配起来会产生四种情况会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫。如果我们继续沿用刚才的设计思路那就需要再定义四个抽象类AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、 AbstractUnFlyableTweetableBird、AbstractUnFlyableUnTweetableBird。 如果我们还需要考虑“是否会下蛋”这样一个行为那估计就要组合爆炸了。类的继承层次会越来越深、继承关系会越来越复杂。而这种层次很深、很复杂的继承关系一方面会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性必须阅读父类的代码、父类的父类的代码……一直追溯到最顶层父类的代码。另一方面这也破坏了类的封装特性将父类的实现细节暴露给了子类。子类的实现依赖父类的实现两者高度耦合一旦父类代码修改就会影响所有子类的逻辑。
总之继承最大的问题就在于继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性。这也是为什么我们不推荐使用继承。那刚刚例子中继承存在的问题我们又该如何来解决呢你可以先自己思考一下再听我下面的讲解。
组合相比继承有哪些优势
实际上我们可以利用组合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 {// 鸵鸟//... 省略其他属性和方法...Overridepublic void tweet() { //... }Overridepublic void layEgg() { //... }
}public class Sparrow impelents Flayable, Tweetable, EggLayable {// 麻雀//... 省略其他属性和方法...Overridepublic void fly() { //... }Overridepublic void tweet() { //... }Overridepublic void layEgg() { //... }
}
复制
不过我们知道接口只声明方法不定义实现。也就是说每个会下蛋的鸟都要实现一遍 layEgg() 方法并且实现逻辑是一样的这就会导致代码重复的问题。那这个问题又该如何解决呢
我们可以针对三个接口再定义三个实现类它们分别是实现了 fly() 方法的 FlyAbility类、实现了 tweet() 方法的 TweetAbility 类、实现了 layEgg() 方法的 EggLayAbility类。然后通过组合和委托技术来消除代码重复。具体的代码实现如下所示
public interface Flyable {void fly();
}
public class FlyAbility implements Flyable {Overridepublic void fly() { //... }
}// 省略 Tweetable/TweetAbility/EggLayable/EggLayAbility
public class Ostrich implements Tweetable, EggLayable {// 鸵鸟private TweetAbility tweetAbility new TweetAbility(); // 组合private EggLayAbility eggLayAbility new EggLayAbility(); // 组合//... 省略其他属性和方法...Overridepublic void tweet() {tweetAbility.tweet(); // 委托}Overridepublic void layEgg() {eggLayAbility.layEgg(); // 委托}
}
复制
我们知道继承主要有三个作用表示 is-a 关系支持多态特性代码复用。而这三个作用都可以通过其他技术手段来达成。比如 is-a 关系我们可以通过组合和接口的 has-a关系来替代多态特性我们可以利用接口来实现代码复用我们可以通过组合和委托来实现。所以从理论上讲通过组合、接口、委托三个技术手段我们完全可以替换掉继承在项目中不用或者少用继承关系特别是一些复杂的继承关系。
如何判断该用组合还是继承
尽管我们鼓励多用组合少用继承但组合也并不是完美的继承也并非一无是处。从上面的例子来看继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着我们要定义更多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。所以在实际的项目开发中我们还是要根据具体的情况来具体选择该用继承还是组合。
如果类之间的继承结构稳定不会轻易改变继承层次比较浅比如最多有两层继承关系继承关系不复杂我们就可以大胆地使用继承。反之系统越不稳定继承层次很深继承关系复杂我们就尽量使用组合来替代继承。
除此之外还有一些设计模式会固定使用继承或者组合。比如装饰者模式decorator pattern、策略模式strategy pattern、组合模式composite pattern等都使用了组合关系而模板模式template pattern使用了继承关系。
前面我们讲到继承可以实现代码复用。利用继承特性我们把相同的属性和方法抽取出来定义到父类中。子类复用父类中的属性和方法达到代码复用的目的。但是有的时候从业务含义上A 类和 B 类并不一定具有继承关系。比如Crawler 类和PageAnalyzer 类它们都用到了 URL 拼接和分割的功能但并不具有继承关系既不是父子关系也不是兄弟关系。仅仅为了代码复用生硬地抽象出一个父类出来会影响到代码的可读性。如果不熟悉背后设计思路的同事发现 Crawler 类和PageAnalyzer 类继承同一个父类而父类中定义的却只是 URL 相关的操作会觉得这个代码写得莫名其妙理解不了。这个时候使用组合就更加合理、更加灵活。具体的代码实现如下所示
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 { // feighn client 框架代码//... 省略其他代码...public void encode(String url) { //... }
}public void demofunction(FeignClient feignClient) {//...feignClient.encode(url);//...
}public class CustomizedFeignClient extends FeignClient {Overridepublic void encode(String url) { //... 重写 encode 的实现...}
}// 调用
FeignClient client new CustomizedFeignClient();
demofunction(client);
复制
尽管有些人说要杜绝继承100% 用组合代替继承但是我的观点没那么极端之所以“多用组合少用继承”这个口号喊得这么响只是因为长期以来我们过度使用继承。还是那句话组合并不完美继承也不是一无是处。只要我们控制好它们的副作用、发挥它们各自的优势在不同的场合下恰当地选择使用继承还是组合这才是我们所追求的境界。
Unity自己的代码也是有继承同时想想Unity的各种组件挂在同一个物体上这就是组合的思想
