请不要评论此处使用的不良做法。我只是试图用易于描述的例子来解决这个场景的抽象问题。
我正在尝试建模一个系统，该系统允许用户使用某些配置参数输入名为TASK的实体，然后让TASK执行特定于该任务的操作。
任务定义的一些例子可能是：
*在目录{path}中创建文件{filename}
*将文件{filename}从{source directory}复制到{target directory}
*打开{记事本应用程序}，输入文本{示例文本}并将文件另存为{filename}
*打开{sample.docx}，在第二段末尾输入文本{sample text}。
每个任务都有一个描述性名称和最多5个参数。在上面的示例中，参数括在花括号{}中。将指示用户继续执行上述任务，我们的应用程序将验证它们是否已完成。每项任务必须具有以下功能：
在静态世界中，我会创建以下类：
public abstract class TaskBase
{ public abstract void Perform(param1, ... param5); }
public class TaskFileCopy: TaskBase
{ public override void Perform(param1, ... param5) {} }
问题是，任务几乎可以是任何事情，在编译和部署程序之后，需要添加更多任务。想到的第一个也是最糟糕的事情是继续从TaskBase派生，实现执行，重新编译和重新部署，同时保持以前的任务结果。
这里有两个问题：当我们达到2,000个任务时，我们将拥有最多2,000个派生类，其次，底层的OODB将陷入困境。
我一度想到System.AddIn，但我确信这种情况在OOP设计中有更好的解决方案。
答案 0 :(得分：0)
我怀疑System.AddIn是否适用于此类事情。 IMHO System.AddIn用于更多静态API，而不是用于快速扩展的东西。也许你可以看一下MEF，它更简单，并且基于可扩展性和组合。
正如你所说，继承也不是要走的路，因为拥有2000个派生类将是一场噩梦。
我认为你应该寻找基于组合而不是继承的设计模式。其中有一些。其中之一是Composite模式。使用此模式，您可以拥有一些非常简单的可重用任务，您可以将这些任务组合成更复杂的任务。您可以拥有包含子任务的任务，包括子任务和打开等。
您还可以查看可以在DLR上托管的动态语言。像IronPython一样。您可以创建脚本存储库。每个脚本都是一个任务。
另外，对于灵感，您可以查看Windows Workflow Foundation，特别是活动。
显而易见的是，您需要最大限度地重复使用。当然，这说起来容易做起来难。
祝福，祝你好运。