不同型號的可擴展接口

我正在設計一個API，它定義了兩個不同型號之間的通用接口。通用接口是代表與之通信的外部系統的Peer。 A Client是Peer，它嘗試建立到特定地址的連接。而Server是一個Peer，它接受來自地址子網的連接。不同型號的可擴展接口

public interface Peer { 
    void send(Message m); 
} 

public interface Client extends Peer { 
    InetAddress getAddress(); 
} 

public interface Server extends Peer { 
    String getSubnet(); 
}

使用此API的應用程序將與Peer對象一起使用。正因爲如此，他們的邏輯將不斷要求類型檢查來提取Peer獨有的信息來執行他們的工作。此外，如果有變成另一種類型的應用程序可能會中斷。

Peer p = incomingMessage.getPeer(); 

if (p instanceof ClientPeer) { 
    //do client peer stuff 
} else if (p instanceof ServerPeer) { 
    //do server peer stuff 
} else { 
    //uh oh... 
}

有沒有更清晰的設計方法？一種不需要進行恆定的類型檢查，並且不會因爲新的類型Peer而進一步擴展的缺陷？

來源

2016-01-04 BarryBostwick

也許ClientPeer和ServerPeer應該做他們自己的東西，或者如果他們總是做不同的事情，他們可能不需要子類型的對等體。 – dbugger

客戶端代碼不應該做switch語句這樣https://en.wikipedia.org/wiki/Proxy_pattern是你可能要實施的方法。

有一個有一些抽象方法的接口「對等」。然後有一個建造者/工廠「創建」他們想要的對等的「實例」。然後將其存儲爲您的「同等」變量。這樣，客戶端只需要學習1個API（'peer'），而不必關心所有不同類型的peer。

然而，@dbugger是正確的，如果一個「客戶」和「服務器」的API是如此不同比他們不應該反正延伸的同一類/接口。如果他們有一個SUBSET的方法重疊，然後做一個更有限的接口，涉及該功能。

這聽起來像一個位洪流類型的場景，並「服務器」，在BT不是客戶。他們可以運行客戶端代碼，但這是一個獨立的進程，在同一臺機器上運行，而不是服務器的一部分。（這可能會幫助您清理「對等」邏輯）

來源

2016-01-04 22:04:12 mawalker

使用此API的應用程序將與Peer對象一起使用。正因爲如此，他們的邏輯將不斷要求類型檢查來提取Peer所獨有的信息來執行他們的工作。

如果是這樣，他們不真正與對等對象一起工作，或者Peer的API應該重新設計，因爲他們需要對等體不提供的信息。

通常你通過提取一個通用api並將條件代碼移入子類來解決這個問題。例如。

public class ClientPeer implements Client { 

    public void findAGoodName(){ 
     //do client peer stuff 
    } 
}

有時候你會陷入了「做客戶端對等的東西」的需求，只有方法的調用者有信息的情況。在這種情況下引入另一個界面。例如。

public class ClientPeer implements Client { 

    public void findAGoodName(CallerData callerData){ 
     //do client peer stuff 
    } 
}

PS：查找類，方法等好名字。

來源

2016-01-05 08:12:52

不同型號的可擴展接口

回答

相關問題