Head First 设计模式 —— 设计模式入门

最新推荐文章于 2025-12-28 09:59:57 发布

原创最新推荐文章于 2025-12-28 09:59:57 发布 · 89 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#设计模式 #java #开发语言

文章探讨了在模拟鸭子应用中如何通过抽象和接口实现代码复用，提出了将变化部分独立出来的设计原则。然而，过度依赖接口可能导致代码冗余和复用性降低，强调需要灵活并追求更精炼的代码设计。

一、模拟鸭子应用

1.语言描述：

建立鸭子类来进行复用，但是存在一些可复用方法的不合理之处，举例：橡皮鸭虽然可以复用鸭子类的相关方法，但是会出现橡皮鸭类本身不存在的方法，鸭子类需要增加一个飞行的方法提供给子类进行复用，但是橡皮鸭本身不应该具有相关方法。

2.代码描述：

/**
 * 鸭子
 */
public abstract class Duck {

    public Duck {

    }

    /**
     * 飞行
     */
    public void fly() {
        System.out.println("I can fly");
    }

    /**
     * 叫
     */
    public void quack() {
        System.out.println("Quack");
    }

    /**
     * 游泳
     */
    public void swim() {
        System.out.println("All doucks float, even decoys!");
    }

}

/**
 * 橡皮鸭
 */
public class RubberDuck extends Duck {

}

3.问题：

这样橡皮鸭就出现了本身不存在的方法内容，所以在转换思维的时候我们可能会选择把变化的东西进行抽离出来定义成一个飞行接口和一个叫声的功能接口。

4.代码实现：

/**
 * 飞行接口类
 */
public interface FlyBehavior {

    /**
     * 飞行
     */
    public void fly();

/**
 * 叫接口类
 */
public interface QuackBehavior {

    /**
     * 叫
     */
    public void quack();

}

5.第一个设计原则：

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

6.引入后的反思：

把变化的代码抽离出以后放置接口的做法，其实对于我们来说很常见，而且我以前经常这样做，虽然会预想到后期对代码扩展和维护工作量会相对较大，但是还是自我说服认为业务体量达不到繁重的地步，但实际上我们已经从一个漏洞进入了另一个漏洞，如果使用接口进行相关转换，新增子类越多我们增加的相关代码就会越多，会出现相关重复代码，并且无法进行代码复用，所以不能束缚自己，一直稳定的想法不一定是最优的一定去学习让自己的代码更加精炼