C# 使代码更简单的需要是否证明使用错误的抽象是合理的？

假设我们有一个运行

命令的
CommandRunner
类，当创建
命令时，它会保存在
处理队列中进行处理，如果执行
命令时出现错误，则
命令将移动到
故障队列
进行后续处理，但当一切正常时，
命令将移动到
归档队列
，将不会以任何方式处理
归档队列

指挥官是这样的

class CommandRunner
{
  public CommandRunner(IQueue<Command> processingQueue, 
                       IQueue<Command> faultedQueue, 
                       IQueue<Command> archiveQueue)
  {
     this.processingQueue = processingQueue;
     this.faultedQueue= faultedQueue;
     this.archiveQueue= archiveQueue;
  }

  public void RunCommands()
  {
     while(processingQueue.HasItems)
     {
        var current = processingQueue.Dequeue();
        var result = current.Run();
        if(result.HasError)
           curent.MoveTo(faultedQueue);
        else 
           curent.MoveTo(archiveQueue);
        ...
     }
  }
}

IEnumerable<Command> AllCommands
{
    get
    {
        return Enumerate(archiveQueue).Union(processingQueue).Union(faultedQueue);
    }
}

类的许多部分都需要这样做（将存档作为队列处理，以使代码更简单，如上所示）

即使队列不是最好的抽象，使用它是否有意义，或者我是否必须为归档概念使用另一个抽象。
满足这些要求的其他替代方案有哪些？
当您需要注意队列中项目的顺序时，队列是一种有用的结构。如果您在命令行过程中需要，请注意命令运行的顺序，那么队列是一个不错的选择

如果您不需要有关顺序或命令的信息，也许可以使用列表（位于System.Collections命名空间上）

我认为你的选择很好，在同样的情况下，我将使用队列，我们有一个关于操作系统设计原则的好例子，在操作系统内部（内核上）进程排队等待执行，显然操作系统队列更复杂，因为它们考虑了其他变量，如优先级和CPU利用率，但我们可以了解在流程管理中使用队列之类的数据结构
 请记住，随着时间的推移，代码，尤其是正在运行的代码通常会变得混乱和混乱。为了解决这一问题，好的名字、好的设计和有意义的评论起了作用

如果您不打算处理
archiveQueue
，而它只是已成功处理的消息的存储，则始终可以将其存储为不同的类型（列表、集合、集合，任何适合您需要的类型），然后选择以下两种类型之一：

保留名称
archiveQueue
，并更改基础类型。我会在定义（或注入）的地方留下一条评论：请注意，这可能不是一个实际的队列。名称仅用于一致性原因

将名称更改为
archiveRepository
或类似名称，同时保留队列类型。显然，由于它仍然是一个队列，您会留下一条评论说：注意，这实际上是一个队列

另一件需要记住的事情是，如果您有
n
人在您的代码库上工作，您可能会得到
n+1
关于应该以何种方式完成的不同性能：）
数据结构的名称不必与抽象匹配。只需将变量名更改为
archivedCommands
或不声称它不是的东西。@BenVoigt这与名称无关，而是与注入CommandRunner的数据结构IQueue有关。名称和类型都与合同/承诺和期望/邀请有关。由于队列在列表上没有任何内容，所以第一点是无意义的；但它确实提高了人们对如何/将如何/应该使用它的期望，这是错误的。尤其是如果您永远不会删除第一个项目，那么名称队列会产生误导。所以我会把名字改成ArchiveList或者干脆改成Archive。这听起来仍然像是按时间顺序排列，但避免了邀请排队。。