C# 您将如何规范从一个类到另一个类的方法调用？

所以说我有：

public interface SystemA
{
    void MethodA(string a, string b, int c);
}

在我的申请表中

public class ClientA
{
    public SystemA mSystemA;
    public ClientA()
    {
         mSystemA.MethodA("whatever", "ok", 42);
    }
}

但我想知道如何改变它以满足以下要求

对系统上的方法的调用可能会收到，也可能不会收到特定的响应

期望响应的方法可能会根据发送后经过的时间触发不同的操作，例如再次调用该方法、通知客户端或通知系统

客户端也必须能够接收消息

我希望系统（或接收客户端）的接口是唯一需要更改的东西

最小开销

避免使用单例，因为它们会破坏可重用性并产生紧密耦合

具体地说，我有三个系统（在许多系统中）负责与远程资源进行交互，无法保证对它们接口的调用是否会得到响应，或者何时得到响应，或者，如果响应是有效的——在系统本身和使用它们的客户端中处理这些情况相当复杂，即使有专门指定行为的状态

我尝试过或考虑过但不喜欢的事情：

• 事件系统-您必须为要向系统公开的每个新方法定义新的事件和侦听器，并且每当您更改方法时，您必须更改所有要匹配的事件、所有侦听器等。使用它的开销太大。如果您为每个指定的事件指定了参数，那么将创建大量的工作，但是如果您使事件真正通用，那么您将不得不在发送者和接收者之间来回切换以匹配它们
• 命令-您必须为接收器上的每个方法定义新命令，每次您想要更改它们所依赖的方法时，您必须更改命令。此外，每个命令的构造函数都必须与方法的签名相匹配。我觉得这也会有太多的开销

---

想法？

我不确定我是否理解您的要求（尤其是1让我感到困惑），但我最好的猜测是您正在描述一种典型的异步客户机-服务器通信机制

如果是这样的话，考虑一个消息队列。调用和响应放置在相应的客户端或服务器队列中。调用响应的关联是通过某种cookie或uid完成的。客户端可以跟踪发送请求的时间和接收响应的时间，等等

---

这是否涉及一些开销？当然有。但是，如果您的需求需要开销，那么它真的是开销吗？

没错，但在我的设计中，发送和接收消息被抽象为接口中的方法和操作，因此消息队列必须位于该类和客户机类之间。我使用消息队列之类的东西时遇到的问题是，在创建消息时，我在发送消息的类和接收者接口之间创建了一层间接层，我不需要它，因为接口就是为了这个。如果我有一个与方法a的接口，并且我想向实现该接口的类发送一条消息，那么我必须创建一个msg子类，该子类再次单独定义一个