方法、接口、反射和一个困难的OOP设计

answer I posted earlier.

为了回答您的具体问题,您应该在这里稍微小心一点,因为您可能会进入 Architecture Astronaut 领土(不是一件好事)。如果每个对象的界面没有自然重叠,那么通过奇怪的设计强迫它们共享概念界面只会让用户感到困惑。你 可以 通过实现接口来解决此问题,接口调用“足够接近”函数,用于非常广泛的概念类别(例如,文件和应用程序都是“打开的”,但结果各不相同)。您还可以在需要显示可用选项的位置使用反射来发现有关对象的更多信息。因此,你 可以 应该 你能做到吗?

public interface IDiscoverableAction {
    string Name { get; }
    void Execute();
}

public interface IHasDiscoverableActions {
   IEnumerable<IDiscoverableAction> DiscoverActions();
}

我同意马克的警告,要仔细考虑你为什么要这么做。调用直到运行时才知道其身份的方法/操作对我来说是个坏主意。

但如果你必须这样做,这里还有另一个想法:让你的 IAction 与 getActions() getActions() callAction(string) 方法调用IAction接口,每个类实现该接口以根据参数调用适当的方法。它可能比使用内置反射机制快一点。

你正在执行。你可以反思并发现你有一个移动方法,但是这个移动方法做什么呢?如果该方法有参数,您也可以发现这些参数,但是从参数的名称中,您是否会有某种AI来确定每个参数名称的含义?

我想象的是,您希望构建一种执行上下文或引擎,并且引擎正在使用的这些对象需要一般地传递到引擎中。一旦引擎抓住对象,引擎就需要弄清楚如何处理对象。。。

假设这是正确的,您可以使用继承从基类(例如FrameworkObject)继承,也可以实现公共接口(例如IFrameworkObject)。您可以选择将接口用作多态“标记”接口。这在当时的ActiveX组件编程中是必需的。我更喜欢marker接口,因为从框架重构生命周期的角度来看,类继承并不是一件微不足道的事情,而且由于添加了一些(但不是全部)派生类所需的特性,它可能会由于基类膨胀而创建混乱的代码。

在通过接口标识确定执行上下文之后(不要自欺欺人地认为可以在方法粒度级别执行),下一个决定是是否尝试使用反射和硬编码逻辑来执行各种方法。如果您想使其非常通用,可以依赖存储在文件或数据库中的元数据来驱动逻辑。例如,执行引擎可以在启动时加载支持的接口,然后使用反射来查询实现iframewobject接口的任何对象。

也许你弄错了。对象是否应该实际实现这些操作?

拿文件。让文件系统对象实现删除操作不是更自然吗?

在任何情况下,您都可以通过引入几个间接层来构建一个真正动态的系统。

假设您根据Deletable将DeleteAction实现为一个UnaryOperation。

将DeleteAction添加到ActionRepository会将其注册为可删除对象。

若要避免将文件静态绑定到可删除,可以引入AdapterRepositor,在其中添加File2Deleteable适配器。

然后,listActions(Object o)将为您提供一个所有操作的列表,这些操作可以直接用于文件或文件的任何可用适配器。