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

最近看到一個有趣的問題：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 是一個抽象工廠，

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

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

不變：

時代一旦確定就不會更改（無需使用狀態模式）
Person的組件一旦確定就不會更改
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());
    }
}

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/550622.html

標籤：Java

上一篇：boot-admin整合flowable官方editor-app進行BPMN2.0建模

下一篇：返回列表