不同型号的可扩展接口

我正在设计一个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

不同型号的可扩展接口

回答

相关问题