可以替代链式 switch/goto 的设计模式吗？

Question

我有一个用于将我的应用程序资源更新到当前应用程序版本的代码。 该代码在应用程序更新后调用。

int version = 1002;   // current app version

switch(version)
{
   case 1001:
      updateTo1002();
      goto case 1002;

   case 1002:
      updateTo1003();
      goto case 1003;

   case 1003:
      updateTo1004();
      goto case 1004;
      break;

   case 1004:
      updateTo1005();
      break;
}

这里我们通过跳转到指定的 case 块来调用级联方法。 我想知道 - 在这种情况下使用 go to 是一个好的做法（通常被认为是不好的做法！）吗？ 我不想一个接一个地调用方法 - 像这样：

updateTo1002()
{
   // do the job
   updateTo1003();
}
updateTo1003()
{
   // do the job
   updateTo1004();
}

是否有任何设计模式描述了这样的问题？

Answer 1

我讨厌不提供支持信息的空白语句，但 goto 受到相当普遍的批评（有充分的理由），并且有更好的方法来实现相同的结果。您可以尝试责任链模式，该模式将获得相同的结果，而无需“意大利面条- goto 实现可以变成“ish” goo。

责任链模式。

Answer 2

goto 始终被认为是不好的做法。如果您使用 goto，通常会更难阅读代码，并且您总是可以以不同的方式编写代码。

例如，您可以使用链表来创建方法链和一些处理该链的处理器类。 （请参阅 pst 的答案以获得很好的示例。）。它更加面向对象且易于维护。或者，如果您必须在 1003 和 case 1004 之间添加一个方法调用怎么办？

当然，请参阅这个问题。

Answer 3

我建议使用命令模式的变体，每个命令都是自我验证的：

interface IUpgradeCommand<TApp>()
{
    bool UpgradeApplies(TApp app);
    void ApplyUpgrade(TApp app);
}

class UpgradeTo1002 : IUpgradeCommand<App>
{
    bool UpgradeApplies(App app) { return app.Version < 1002; }

    void ApplyUpgrade(App app) {
        // ...
        app.Version = 1002;
    }
}

class App
{
    public int Version { get; set; }

    IUpgradeCommand<App>[] upgrades = new[] {
        new UpgradeTo1001(),
        new UpgradeTo1002(),
        new UpgradeTo1003(),
    }

    void Upgrade()
    {
        foreach(var u in upgrades)
            if(u.UpgradeApplies(this))
                u.ApplyUpgrade(this);
    }
}

Answer 4

为什么不呢：

int version = 1001;

upgrade(int from_version){
  switch (from_version){
    case 1000:
      upgrade_1000();
      break;
    case 1001:
      upgrade_1001();
      break;
    .
    .
    .
    .
    case 4232:
      upgrade_4232();
      break;
  }
  version++;
  upgrade(version);
 }

当然，所有这些递归都会产生开销，但并没有那么多（调用碳水化合物收集器时只有一个上下文和一个 int），并且所有这些都被打包起来。

请注意，我不太介意这里的 goto，并且元组 (int:action) 变体也有其优点。

编辑：

对于那些不喜欢递归的人：

int version = 1001;
int LAST_VERSION = 4233;

While (version < LAST_VERSION){
  upgrade(version);
  version++;
}

upgrade(int from_version){
  switch (from_version){
    case 1000:
      upgrade_1000();
      break;
    case 1001:
      upgrade_1001();
      break;
    .
    .
    .
    .
    case 4232:
      upgrade_4232();
      break;
  }

}

Answer 5

我想说这是使用 GOTO 功能的一个非常充分的理由。

http://weblogs .asp.net/stevewellens/archive/2009/06/01/why-goto-still-exists-in-c.aspx

事实上，C#中的switch()语句是实际上是标签集合和隐藏的 goto 操作的漂亮面孔。 case 'Foo': 只是在 switch() 范围内定义标签类型的另一种方式。

Answer 6

我认为这里的逻辑可能有些落后并导致了问题。如果您的方法如下所示怎么办：

updateTo1002() 
{ 
   if (version != 1001) {
       updateTo1001();
   }
   // do the job     
} 
updateTo1003() 
{ 
   if (version != 1002) {
       updateTo1002();
   }
   // do the job     
} 

我不知道您的确切用例，但在我看来，您通常希望更新到最新版本，但在此过程中根据需要安装增量更新。我认为这样做可以更好地捕捉逻辑。

编辑：来自@user470379的评论

在这种情况下，主要是确定您有复制/粘贴模式并对其进行编辑。

在这种情况下，耦合问题几乎不是一个问题，但也可能是一个问题。我将向您提供一些在您的场景中可能出现的事情，如果这样做的话将很难编码：

• 现在每次更新都需要一个额外的清理步骤，因此在 updateTo1001() 调用 cleanup() 等之后。
• 您需要能够后退一步以测试旧版本
• 您需要在 1001 和 1002 之间插入更新

让我们按照您的模式组合这两个版本。首先，让我们添加一个“undoUpgradeXXXX()”来撤消每次升级并能够后退。现在您需要第二组并行的 if 语句来执行撤消操作。

现在，让我们添加“插入 1002.5”。突然之间，您正在重写两个可能很长的 if 语句链。

您将遇到此类问题的关键迹象是您正在按照某种模式进行编码。留意这样的模式——事实上，我的第一个迹象通常是当我越过某人的肩膀查看他们的代码时，如果我可以看到一个模式，甚至无法阅读这样写的任何内容：

********
   ***
   *****

********
   ***
   *****
...

那么我知道他们的代码我会遇到问题。

最简单的解决方案通常是删除每个“组”中的差异并将它们放入数据（通常是数组，不一定是外部文件）中，将组折叠到循环中并迭代该数组。

对于您的情况，简单的解决方案是使用单一升级方法来制作每个升级对象。创建这些对象的数组，并在需要升级时迭代它们。您可能还需要某种方法来对它们进行排序 - 您当前使用的数字可能有效 - 或者日期可能更好 - 这样您就可以轻松“转到”给定日期。

现在有一些区别：

• 向每次迭代（cleanup()）添加新行为将是对循环的单行修改。
• 重新排序将被本地化以修改您的对象——可能甚至更简单。
• 将升级分为多个必须按顺序调用的步骤很容易。

让我给你举一个最后一个例子。假设在运行所有升级后，您需要为每个升级执行初始化步骤（每种情况都不同）。如果您向每个对象添加一个初始化方法，那么对初始循环的修改是微不足道的（只需在循环中添加第二次迭代）。在您的原始设计中，您必须复制、粘贴和粘贴。编辑整个 if 链。

结合“JUST 撤消”和“JUST 撤消”初始化并且你有 4 个 if 链。最好在开始之前找出问题。

我还可以说，消除这样的代码可能很困难（根据您的语言，这非常困难）。在 Ruby 中，这实际上非常简单，在 Java 中，这需要一些练习，但许多人似乎做不到，因此他们认为 Java 不灵活且困难。

花一个小时到处思考如何减少这样的代码对我的编程能力的提升比我读过的任何书籍或接受过的培训都要多。

这也是一个挑战，给你一些事情做，而不是编辑巨大的 if 链寻找复制/粘贴错误，你忘记将 8898 更改为 8899。老实说，它使编程变得有趣（这就是为什么我花了这么多时间在这个答案上） ）

Answer 7

正确的方法是使用继承和多态性，如下所示：

首先，请注意，在各种情况下执行的代码之间存在明确的层次关系。 IE。第一个案例完成了第二个案例的所有工作，然后还有更多。第二个案例完成了第三个案例的所有工作，然后还有更多。

因此，创建一个类层次结构：

// Java used as a preference; translatable to C#
class Version {
    void update () {
        // do nothing
    }
}

class Version1001 extends Version {
    @Override void update () {
        super.update();
        // code from case update 1001
    }
}

class Version1002 extends Version1001 {
    @Override void update () {
        super.update();
        // code from case update 1002
    }
}

class Version1003 extends Version1002 {
    @Override void update () {
        super.update();
        // code from case update 1003
    }
}

// and so forth

其次，使用虚拟分派（又称多态性），而不是 switch-case：

Version version = new Version1005();
version.update();

讨论（对于不相信的人）：

1. 使用目标中立的 super.update() 代替 goto，并在类层次结构“Version1002扩展Version1001”
2. 这不依赖于版本号之间的算术关系（与上面的流行答案不同），因此您可以优雅地执行诸如“VersionHelios扩展VersionGalileo”之类的操作
3. 此类可以集中任何其他特定于版本的功能，例如as @Override String getVersionName () { return "v1003"; } }

Answer 8

我认为没关系，尽管我怀疑这是您的真实代码。您确定不需要将 Update 方法封装在 AppUpdate 类或其他内容中吗？事实上，你有名为 XXX001、XXX002 等的方法，这不是一个好兆头，IMO。

反正。这是代表的另一种选择（并不是真正建议您使用它，只是一个想法）：

var updates = new Action[] 
                 {updateTo1002, updateTo1003, updateTo1004, updateTo1005};

if(version < 1001 || version > 1004)
   throw new InvalidOperationException("...");    

foreach(var update in updates.Skip(version - 1001))
   update();

如果没有更多细节，很难推荐最合适的模式。

Answer 9

我曾评论说，使用 goto 永远不值得你为使用它而付出代价（即使它是一个很棒、完美的用法）——太多的程序员学到了一些东西，却永远无法将其从他们的大脑中解脱出来。

我不打算发布答案，但我认为它还不够清楚，您暗示的整个解决方案都是错误的。我以为这只是为了表达你的观点，但应该明确：要非常小心代码中的模式——这和复制/粘贴代码一样糟糕（事实上，它是复制/粘贴代码）。

您应该只有一个对象集合，每个对象都有升级代码和版本号。

您只需在版本号 < 时迭代该集合即可。您的目标版本，并为每个对象调用该对象的升级代码。通过这种方式，要创建新的升级级别，您只需制作一个“升级”对象并将其粘贴到集合中即可。

您的升级对象链甚至可以通过添加撤消和向控制器添加非常简单的代码来向后和向前遍历 - 这将成为使用示例代码进行维护的噩梦。

Answer 10

您可以查看状态机工作流程模式。对您来说简单且有用的可能是：无状态项目

Answer 11

我不得不处理一些这样的问题（将文件转换为这种格式，以便它可以转换为其他格式等），并且我不喜欢 switch 语句。带有“if”测试的版本可能会很好，或者递归地进行类似的操作可能会很好：

/* Upgrade to at least version 106, if possible.  If the code
   can't do the upgrade, leave things alone and let outside code
   observe unchanged version number */

void upgrade_to_106(void)
{
  if (version < 105)
    upgrade_to_105();
  if (version == 105)
  {
    ...
    version = 106;
  }
}

除非您有数千个版本，否则堆栈深度不应该成为问题。我认为 if-test 版本，专门测试每个升级例程可以处理的版本，读起来更好；如果最后的版本号不是主代码可以处理的版本号，则发出错误信号。或者，删除主代码中的“if”语句并将它们包含在例程中。我不喜欢“case”语句，因为它没有考虑版本更新例程可能不起作用或一次可能更新多个级别的可能性。

Answer 12

那么，如果我们想要“面向对象”，为什么不让对象来说话呢？

var updates = availableUpdates.Where(u => u.version > ver).OrderBy(u => u.version);
foreach (var update in updates) {
  update.apply();
}

Answer 13

在示例中，版本不断增加，并且始终按顺序调用较早的版本。我认为一组 if 语句在这里可能更合适。

if (version == 1001 ) { 
  updateTo1002();
}

if (version <= 1002) {
  updateTo1003();
}

if (version <= 1003) {
  updateTo1004(); 
}

if (version <= 1004) {
  updateTo1005();
}

有些人评论说，随着版本数量增加（想想 50 左右），这种方法无法维护。在这种情况下，这是一个更容易维护的版本

private List<Tuple<int, Action>> m_upgradeList;

public Program()
{
    m_upgradeList = new List<Tuple<int, Action>> {
        Tuple.Create(1001, new Action(updateTo1002)),
        Tuple.Create(1002, new Action(updateTo1003)),
        Tuple.Create(1003, new Action(updateTo1004)),
        Tuple.Create(1004, new Action(updateTo1005)),
    };
}

public void Upgrade(int version)
{
    foreach (var tuple in m_upgradeList)
    {
        if (version <= tuple.Item1)
        {
            tuple.Item2();
        }
    }
}