适用于不同型号的可扩展接口

Question

我正在设计一个API，它定义了两个不同模型之间的公共接口。公共接口是Peer，它表示要与之通信的外部系统。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应用程序，则可能会崩溃。

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进一步扩展自己不会有缺陷吗？

Answer 1

客户端代码不应该执行这样的切换语句https://en.wikipedia.org/wiki/Proxy_pattern是您可能想要实现的一种方法。

有一个具有一些抽象方法的接口"peer"。然后有一个构建器/工厂来"创建"他们想要的对等体的"实例"。然后将其存储为"peer"变量。这样，客户只需学习1个API（"对等"），而不必关心所有不同类型的对等。

然而，@dbugger正确地认为，如果"客户端"one_answers"服务器"的API如此不同，那么它们无论如何都不应该扩展相同的类/接口。如果它们确实有重叠的方法子集，那么就创建一个与该功能相关的更有限的接口。

这听起来像是Bit torrent类型的场景，BT中的"服务器"不是客户端。它们可以运行客户端代码，但这是在同一台机器上运行的单独进程，而不是服务器的一部分。（这可能有助于您理清"对等"的逻辑）

Answer 2

使用此API的应用程序将使用对等对象。正因为如此，他们的逻辑将不断地需要类型检查来提取对等体唯一的信息来执行他们的工作。

如果是这样的话，它们就不能真正处理对等对象，或者应该重新设计对等对象的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：为类、方法等查找好的名称。