沒有杯子的世界：OOP設計思想的應用實踐

来源:https://www.cnblogs.com/dahua-dijkstra/archive/2023/04/20/17338189.html
-Advertisement-
Play Games

最近看到一個有趣的問題：Person類具有Hand,Hand可以操作杯子Cup,但是在石器時代是沒有杯子的，這個問題用編程怎麼解決？ 簡單代碼實現 我們先用簡單代碼實現原問題： @Data public class Person { private final String name; privat ...


最近看到一個有趣的問題：Person類具有Hand,Hand可以操作杯子Cup,但是在石器時代是沒有杯子的，這個問題用編程怎麼解決？

簡單代碼實現

我們先用簡單代碼實現原問題：


@Data
public class Person {
    private final String name;
    private Hand hand = new Hand();

    private Mouth mouth = new Mouth();

    private static class Hand {
        // 為了簡化問題，用字元串表示覆雜的方法實現，這些方法極有可能具有副作用
        String holdCup() {
            return "hold a cup...";
        }

        String refillCup() {
            return "refill the coffee cup...";
        }
    }

    private static class Mouth {
        String drinkCoffee() {
            return "take a cup of coffee";
        }
    }

    public String drinkCoffee() {
        return String.join("\n",
                hand.refillCup(),
                hand.holdCup(),
                mouth.drink()
        );
    }
    // 略去其他方法，run(), work(), eat()...

    public static void main(String[] args) {
        Person eric = new Person("Eric");
        System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
    }
}

良好的代碼設計經常面向介面編程，我們抽取出介面如下:

public interface Person {
    String drinkCoffee();
    // 略去其他方法，run(), work(), eat()...

    interface Hand {
        String holdCup();

        String refillCup();
    }

    interface Mouth {
        String drinkCoffee();
    }
}

@Data
public class DefaultPerson implements Person {
    private final String name;
    private Hand hand = new DefaultHand();

    private Mouth mouth = new DefaultMouth();

    private static class DefaultHand implements Hand {
        @Override
        public String holdCup() {
            return "hold a cup...";
        }

        @Override
        public String refillCup() {
            return "refill the coffee cup...";
        }
    }

    private static class DefaultMouth implements Mouth {
        @Override
        public String drinkCoffee() {
            return "take a cup of coffee";
        }
    }

    @Override
    public String drinkCoffee() {
        return String.join("\n",
                hand.refillCup(),
                hand.holdCup(),
                mouth.drinkCoffee()
        );
    }

    public static void main(String[] args) {
        Person eric = new DefaultPerson("eric");
        System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
    }
}

完事具備，現在我們來思考下這個問題： 問題的關鍵在於drinkCoffee方法，現在這個方法調用的結果是不對的，因為方法的調用依據了 DefaultPerson 之外的變數，即是否處於石器時代。 我們先看一個不好的實現：


@Value
public class BadPersonImpl implements Person {
    String name;
    boolean isInStoneEra;

    @Override
    public String drinkCoffee() {
        if (isInStoneEra) {
            return String.format("%s cannot drink, because there is no cup in the era.", getName());
        }
        return "refill the coffee cup..." + "hold a cup..." + "take a cup of coffee.";
    }

    public static void main(String[] args) {
        Person eric = new BadPersonImpl("Eric", true);
        System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
    }
}

這段代碼的問題是所有的內容都寫死了，所有的代碼都在一塊，無法復用和拓展。

當然，如果說本來 Person 的實現就簡單，新需求並不多，用這種方法也不是不可以。

問題分析&解決方法

不過，大部分情況下如果我們最開始這麼寫，把自己的路堵死了，當有新需求時，之後的修改極有可能發展成 if-else 套娃地獄，一個方法越寫越多，越寫越亂， 邏輯複雜到自己把自己都繞死了，最後實在受不了了，重寫整個方法或類。

為什麼我的代碼中新加了 Mouth 這個類？

因為如果Person中有Hand這個類，通常說明 Hand類 有自己獨立的實現，行為比較複雜，Person 實現的行為比較複雜， 加入了 Mouth 是為了說明 Person 類的複雜性，Person 是一個抽象工廠。

正確的做法應該考慮設計中的變數和不變數：

  1. 人所處的時代是變化的，時代影響人的行為
  2. 人的行為可以獨立變化，即人具有hand、mouth等，其使用各個組件進行某些行為。
  3. 人的組件hand、mouth可以獨立變化

不變：

  1. 時代一旦確定就不會更改（無需使用狀態模式）
  2. Person的組件一旦確定就不會更改
  3. Person 和 Era 獨立擴展

由此我們得出結論，Person 和 Era 要實現解耦。

interface EraEnvironment {
    default boolean hasCup() {
        return true;
    }
}

class ModernEra implements EraEnvironment {
}

class StoneAge implements EraEnvironment {
    @Override
    public boolean hasCup() {
        return false;
    }
}

// 基於組合的實現
@Value
class PersonInEra implements Person {
    Person person;
    EraEnvironment era;

    @Override
    public String drinkCoffee() {
        if (era.hasCup()) {
            return person.drinkCoffee();
        }
        return String.format("%s cannot drink, because there is no cup in the era.", person.getName());
    }

    @Override
    public String getName() {
        return person.getName();
    }

    public static void main(String[] args) {
        PersonInEra eric = new PersonInEra(new DefaultPerson("Eric"), new StoneAge());
        System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
    }
}

進一步優化成協調者模式，可以保證各個 Colleague 類(Person、EraEnvironment)獨立擴展。

如果以後還有影響 Person 行為的變數，比如天氣、心情等，可以引入新的協調者。

可以看出，隨著需求的增多，協調者可能越來越多，此時我們就需要重新進行分析，哪些條件可以看做Person的固有屬性，對Person進行重構。

// 優化抽取出抽象類
class PersonInEra extends AbstractPersonInEra {
    public PersonInEra(Person person, EraEnvironment era) {
        super(person, era);
    }

    @Override
    public String drinkCoffee() {
        if (getEra().hasCup()) {
            return getPerson().drinkCoffee();
        }
        return String.format("%s cannot drink, because there is no cup in the era.", getName());
    }

    public static void main(String[] args) {
        PersonInEra eric = new PersonInEra(new DefaultPerson("Eric"), new StoneAge());
        System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
    }
}

public abstract class AbstractPersonInEra implements Person {
    private final Person person;
    private final EraEnvironment era;

    public AbstractPersonInEra(Person person, EraEnvironment era) {
        this.person = person;
        this.era = era;
    }

    @Override
    public String getName() {
        return person.getName();
    }

    protected Person getPerson() {
        return person;
    }

    protected EraEnvironment getEra() {
        return era;
    }

    @Override
    public abstract String drinkCoffee();
}

面向對象原則分析

當然，根據對需求的不同理解和對未來需求的預期，我們可能選擇不同的實現，這個問題還有可能用狀態模式、策略模式等實現，不同的方法有優點也有缺點； 如果在面試中遇到這樣的問題，一定要跟面試官明確背景和需求。

我們使用面向對象的基本原則分析下改動前後的代碼：

1.單一職責原則（SRP）：一個類/方法應該只有一個職責。

滿足。以 PersonInEra::drinkCoffee 為例，其只負責根據環境，對調用方法進行選擇。

2.開放封閉原則（OCP）：軟體實體應該對擴展開放，對修改關閉。

滿足。對擴展開發不必多說，使用介面或抽象類都方便了拓展。

3.里氏替換原則（LSP）：子類對象應該能夠替換其父類對象並保持系統的行為正確性。

滿足。我們使用時聲明類型為介面 Person，使用的實例為其具體實現。

4.依賴倒置原則（DIP）：高層模塊不應該依賴於底層模塊，而是應該通過抽象進行交互。

滿足。client 使用了Person, Person的不同實現間的依賴都是介面或抽象類。 一個實體類抽象出介面是一個萬金油式的好方法。

5.介面隔離原則（ISP）：一個類對另一個類的依賴應該建立在最小的介面上。

滿足。比如 AbstractPersonInEra 依賴的是 Person介面，這個介面並不包含其他不必要的方法。

6.合成/聚合復用原則（CARP）：優先使用對象合成或聚合，而不是繼承來實現代碼復用。

滿足。AbstractPersonInEra 使用的是組合實現。

7.迪米特法則（LoD）：一個對象應該對其它對象保持最小的瞭解。 滿足。這裡還是看出了使用介面的好處，AbstractPersonInEra 只知道自己依賴了 Person 和 EraEnvironment, 對於依賴對象的實現一無所知。

策略模式

最後，你可以自己寫個策略模式，和我寫的策略模式比較一下，從面向對象設計的角度分析其優劣。

使用策略模式編寫的代碼如下：

// 策略模式，不改變原 DefaultPerson 的實現
@FunctionalInterface
public interface DrinkStrategy {
    String drink();
}

public final class Persons {
    private Persons(){}
    @NotNull
    private static DrinkStrategy stoneEraSupport(Person person, EraEnvironment era) {
        return () -> {
            if (era.hasCup()) {
                return person.drinkCoffee();
            }
            return String.format("%s cannot drink, because there is no cup in the era.", person.getName());
        };
    }

    // 工廠方法創建複雜對象
    @NotNull
    public static Person stoneAgeSupportWithNameAndEra(String name, EraEnvironment era) {
        DefaultPerson oriPerson = new DefaultPerson(name);
        return new StrategicPerson(oriPerson, stoneEraSupport(oriPerson, era));
    }
}

@Value
public class StrategicPerson implements Person {
    // 使用組合
    Person person;

    // 支持多種策略,拓展性好
    DrinkStrategy drinkStrategy;

    @Override
    public String drinkCoffee() {
        return drinkStrategy.drink();
    }

    // 除需要更改的方法外，其他實現委托給原 Person. 比較煩的是：需要委托的方法多的話，都要單獨編寫方法
    @Override
    public String getName() {
        return person.getName();
    }

    public static void main(String[] args) {
        Person eric = Persons.stoneAgeSupportWithNameAndEra("eric", new StoneAge());
        System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
    }
}

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 【備忘錄設計模式詳解】C/Java/JS/Go/Python/TS不同語言實現
    簡介 備忘錄模式（Memento Pattern）是一種結構型設計模式。這種模式就是在不破壞封裝的條件下，將一個對象的狀態捕捉(Capture)住，並放在外部存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態。備忘錄模式常常與命令模式和迭代子模式一同使用。 備忘錄模式的角色有三個：備忘 ...
  • 一種面向後端的微服務低代碼平臺架構設計
    結合京東業務研發實際情況，針對後端研發人員，設計一個微服務低代碼平臺，助力更高效低交付業務需求。現已結業，將我在本次項目中沉澱設計出的設計文檔整理成文，期待與大家有進一步的碰撞溝通 ...
  • Opencv在VS2022中的配置（Python)
    下載Opencv 先去官網https://opencv.org/opencv-4-7-0/下載， 找到適合你設備的版本下載Windows就是Win pack,完成後進行安裝即可，一路同意預設就行，可以更改安裝位置，但路徑上儘可能以英文，以防止後面不必要的問題。 2.下載Python 首先是版本 發文 ...
  • 【Visual Leak Detector】源碼下載
    說明 使用 VLD 記憶體泄漏檢測工具輔助開發時整理的學習筆記。本篇介紹 VLD 源碼的下載。同系列文章目錄可見 《記憶體泄漏檢測工具》目錄 1. 下載途徑 以 v2.5.1 版本為例，可以到 Github-KindDragon-vld 頁面下載 master 的 zip 源碼包，如下所示： 也可以到 ...
  • 原來這就是所謂的 JSR！
    相信大家在學習 Java 的過程中，或多或少都見過 JSR 這個詞。本篇文章就科普下什麼是 JSR。 什麼是 JSR ？ JSR（Java Specification Requests），是指 Java 規範請求（或者活規範提案）。這個請求（提案）是提給 JCP 的（Java Community P ...
  • hackathon 復盤：niche 海外軟體工具正確的方法 6 個步驟
    上周末，去參加了北京思否 hackathon，兩天時間內從腦暴 & 挖掘軟體 IDEA -> Demo 研發路演，這次經歷讓我難忘。這裡我的看法是每個開發者圈友，都應該去參加一次 hackathon ~ 做 niche 軟體正確的方法 這邊先說結論，如圖。我認為 做 niche 軟體正確的方法 或 ...
  • JVM中的編譯器
    JVM中集成了兩種編譯器，Client Compiler和Server Compiler，它們的作用也不同。Client Compiler註重啟動速度和局部的優化，Server Compiler則更加關註全局的優化，性能會更好，但由於會進行更多的全局分析，所以啟動速度會變慢。兩種編譯器有著不同的應用 ...
  • Rust編程語言入門之Rust的面向對象編程特性
    Rust 的面向對象編程特性 一、面向對象語言的特性 Rust是面向對象編程語言嗎？ Rust 受到多種編程範式的影響，包括面向對象 面向對象通常包含以下特性：命名對象、封裝、繼承 對象包含數據和行為 “設計模式四人幫”在《設計模型》中給面向對象的定義： 面向對象的程式由對象組成 對象包裝了數據和操 ...
一周排行
    -Advertisement-
    Play Games
  • WPF 已知問題 監聽 WMI 事件導致觸摸失效
    示例項目結構 在 Visual Studio 中創建一個 WinForms 應用程式後，項目結構如下所示： MyWinFormsApp/ │ ├───Properties/ │ └───Settings.settings │ ├───bin/ │ ├───Debug/ │ └───Release/ ...
  • [STAThread]特性
    [STAThread] 特性用於需要與 COM 組件交互的應用程式，尤其是依賴單線程模型（如 Windows Forms 應用程式）的組件。在 STA 模式下，線程擁有自己的消息迴圈，這對於處理用戶界面和某些 COM 組件是必要的。 [STAThread] static void Main(stri ...
  • UWP WinUI3 傳入 AddHandler 的 RoutedEventHandler 類型與事件所需不匹配將拋出參數異常
    在WinForm中使用全局異常捕獲處理 在WinForm應用程式中，全局異常捕獲是確保程式穩定性的關鍵。通過在Program類的Main方法中設置全局異常處理，可以有效地捕獲並處理未預見的異常，從而避免程式崩潰。 註冊全局異常事件 [STAThread] static void Main() { / ...
  • .NET 多版本 WinForm 開源控制項庫 SunnyUI
    前言 給大家推薦一款開源的 Winform 控制項庫，可以幫助我們開發更加美觀、漂亮的 WinForm 界面。 項目介紹 SunnyUI.NET 是一個基於 .NET Framework 4.0+、.NET 6、.NET 7 和 .NET 8 的 WinForm 開源控制項庫，同時也提供了工具類庫、擴展 ...
  • .net core8 使用Swagger（附當前源碼）
    說明 該文章是屬於OverallAuth2.0系列文章，每周更新一篇該系列文章（從0到1完成系統開發）。 該系統文章，我會儘量說的非常詳細，做到不管新手、老手都能看懂。 說明：OverallAuth2.0 是一個簡單、易懂、功能強大的許可權+可視化流程管理系統。 有興趣的朋友，請關註我吧(*^▽^*) ...
  • WPF 什麼時候 VisualTreeHelper.GetDescendantBounds 將返回無窮大
    一、下載安裝 1.下載git 必須先下載並安裝git，再TortoiseGit下載安裝 git安裝參考教程：https://blog.csdn.net/mukes/article/details/115693833 2.TortoiseGit下載與安裝 TortoiseGit，Git客戶端，32/6 ...
  • C# 開源教程帶你輕鬆掌握數據結構與演算法
    前言 在項目開發過程中，理解數據結構和演算法如同掌握蓋房子的秘訣。演算法不僅能幫助我們編寫高效、優質的代碼，還能解決項目中遇到的各種難題。 給大家推薦一個支持C#的開源免費、新手友好的數據結構與演算法入門教程：Hello演算法。 項目介紹 《Hello Algo》是一本開源免費、新手友好的數據結構與演算法入門 ...
  • 第22篇 生成proto文件bat腳本
    1.生成單個Proto.bat內容 @rem Copyright 2016, Google Inc. @rem All rights reserved. @rem @rem Redistribution and use in source and binary forms, with or with ...
  • 記一次 .NET某上位機視覺程式 卡死分析
    一：背景 1. 講故事 前段時間有位朋友找到我，說他的窗體程式在客戶這邊出現了卡死，讓我幫忙看下怎麼回事？dump也生成了，既然有dump了那就上 windbg 分析吧。 二：WinDbg 分析 1. 為什麼會卡死 窗體程式的卡死，入口門檻很低，後續往下分析就不一定了，不管怎麼說先用 !clrsta ...
  • 醫學DICOM文件與PACS系統進行數據傳輸
    前言 人工智慧時代，人臉識別技術已成為安全驗證、身份識別和用戶交互的關鍵工具。 給大家推薦一款.NET 開源提供了強大的人臉識別 API，工具不僅易於集成，還具備高效處理能力。 本文將介紹一款如何利用這些API，為我們的項目添加智能識別的亮點。 項目介紹 GitHub 上擁有 1.2k 星標的 C# ...
所有分類