最近看到一個有趣的問題：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 是一個抽象工廠。
正確的做法應該考慮設計中的變數和不變數：
不變：
由此我們得出結論，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());
}
}