在这种情况下我该如何替换instanceof？

Question

我正在尝试比较compareCriteria。简单的，如 ' Between' 和 'inArray' 或 'greaterThan'。我对这些类使用多态性。他们从compareCriteria接口共享的一种方法是“matchCompareCriteria”。

我试图避免的是让每个类检查它们应该匹配的比较条件的类型。例如，inArray 对象将检查 matchCompareCriteria 是否传递了 inArray 对象，如果没有，它将返回 false，如果是，它知道如何比较。

也许在这种情况下，instanceof是完全合法的（对象知道它们自己），但我仍然在寻找可能的方法来避免它。有什么想法吗？

伪代码示例：

betweenXandY = create new between class(x, y)
greaterThanZ = create new greaterThan class(z)
greaterThanZ.matchCompareCriteria(betweenXandY)

如果 X 和 Y 大于 Z，则返回 true。

编辑：

1）instanceof是我现在看到的，根据matchCompareCriteria方法的需要。我想摆脱它

2）matchCompareCritera 检查compareCriteria 是否被另一个包含。如果一个值的所有可能值都包含在另一个值中，则返回 true。对于compareCriteria 的许多组合来说，比较它们甚至没有意义，因此它们返回 false（例如 BetweenAlfa 和 BetweenNum 是不兼容的）。

Answer 1

您描述的问题称为双重调度。该名称源自这样一个事实：您需要根据两个对象的类型（因此：double）来决定执行（分派）哪一段代码。

通常，在面向对象中，存在单次调度 - 调用对象上的方法会导致该对象的方法实现执行。

在您的情况下，您有两个对象，要执行的实现取决于两个对象的类型。从根本上来说，当您以前只处理过标准的 OO 情况时，这隐含着一种耦合，这种耦合“感觉不对”。但这并不是真正的错误 - 它只是稍微超出了 OO 的基本功能直接适合解决的问题范围。

如果您使用动态语言（或具有反射的静态类型语言，对于此目的来说它足够动态），您可以使用基类中的调度程序方法来实现它。用伪代码表示：

class OperatorBase
{
    bool matchCompareCriteria(var other)
    {
        var comparisonMethod = this.GetMethod("matchCompareCriteria" + other.TypeName);
        if (comparisonMethod == null)
            return false;

        return comparisonMethod(other);
    }
}

在这里，我想象该语言在每个类中都有一个名为 GetMethod 的内置方法，它允许我按名称查找方法，并且每个对象上都有一个 TypeName 属性这让我得到了对象类型的名称。因此，如果另一个类是 GreaterThan，并且派生类有一个名为 matchCompareCriteriaGreaterThan 的方法，我们将调用该方法：

class SomeOperator : Base
{
    bool matchCompareCriteriaGreaterThan(var other)
    {
        // 'other' is definitely a GreaterThan, no need to check
    }
}

因此，您只需编写一个具有正确名称的方法，然后就会发生分派。

在支持按参数类型重载方法的静态类型语言中，我们可以避免必须发明串联命名约定 - 例如，这里是 C# 中的：

class OperatorBase
{
    public bool CompareWith(object other)
    {
        var compare = GetType().GetMethod("CompareWithType", new[] { other.GetType() });
        if (compare == null)
            return false;

        return (bool)compare.Invoke(this, new[] { other });
    }
}

class GreaterThan : OperatorBase { }
class LessThan : OperatorBase { }

class WithinRange : OperatorBase
{
    // Just write whatever versions of CompareWithType you need.

    public bool CompareWithType(GreaterThan gt)
    {
        return true;
    }

    public bool CompareWithType(LessThan gt)
    {
        return true;
    }
}

class Program
{
    static void Main(string[] args)
    {
        GreaterThan gt = new GreaterThan();
        WithinRange wr = new WithinRange();

        Console.WriteLine(wr.CompareWith(gt));
    }
}

如果要向模型添加新类型，则需要查看询问自己是否需要以某种方式与新类型进行交互。因此，每种类型都必须定义一种与所有其他类型交互的方式 - 即使交互是一些非常简单的默认值（例如“除了 return true 之外什么也不做”）”）。即使是简单的默认设置也代表着您必须做出的深思熟虑的选择。这是因为在最常见的情况下不必显式编写任何代码的便利性所掩盖。

因此，捕获外部表中所有类型之间的关系可能更有意义，而不是将其分散在所有对象周围。集中它的价值在于，您可以立即查看是否错过了类型之间的任何重要交互。

因此，您可以拥有一个字典/映射/哈希表（无论在您的语言中如何称呼）将一种类型映射到另一个字典。第二个字典将第二类型映射到这两种类型的正确比较函数。一般的 CompareWith 函数将使用该数据结构来查找要调用的正确比较函数。

哪种方法是正确的取决于您的模型最终可能有多少类型。

Answer 2

由于您引用了 instanceof，我假设我们在这里使用 Java 进行工作。这可能会让您利用重载。考虑一个名为 SomeInterface 的接口，它只有一个方法：

public interface SomeInterface {
    public boolean test (SomeInterface s);
}

现在，我们定义两个（巧妙命名的）类来实现 SomeInterface：Some1 和 <代码>Some2。 Some2 很无聊：test 总是返回 false。但是，当给定 Some2 时，Some1 会覆盖 test 函数：

public class Some1 implements SomeInterface {
    public boolean test (SomeInterface s) {
        return false;
    }

    public boolean test (Some2 s) {
        return true;
    }
}

这可以让我们避免使用一行又一行的 if 语句来进行类型检查。但有一个警告。考虑这段代码：

Some1 s1 = new Some1 ();
Some2 s2 = new Some2 ();
SomeInterface inter = new Some2 ();

System.out.println(s1.test(s2));     // true
System.out.println(s2.test(s1));     // false
System.out.println(s1.test(inter));  // false

看到第三个测试了吗？即使 inter 的类型为 Some2，它也会被视为 SomeInterface。 Java 中的重载解析是在编译时确定的，这可能会使其对您完全无用。

这会让您回到第一个方向：使用 instanceof （在运行时评估）。即使你这样做，它仍然是一个糟糕的设计。您的每个班级都必须了解所有其他班级。如果您决定添加另一个类，则必须返回所有现有类来添加处理新类的功能。这很快就会变得非常难以维护，这是一个好的迹象，表明设计很糟糕。

重新设计是有序的，但如果没有更多的信息，我无法给你一个特别好的推动，让你朝着正确的方向前进。

Answer 3

您需要创建一个名为 Criteria 的超类或接口。然后每个具体子类将实现 Criteria 接口。介于、大于等是标准。

Criteria 类将指定接受 Criteria 的 matchCompareCriteria 方法。实际逻辑将驻留在子类中。

您正在寻找策略设计模式或模板设计模式。

Answer 4

如果我理解得很好，你的方法依赖于类型检查。这是很难避免的，而多态性并不能解决这个问题。从您的示例中，inArray 需要检查参数的类型，因为方法的行为取决于此。您不能通过多态性来做到这一点，这意味着您不能在类上放置多态方法来处理这种情况。这是因为您的 matchCompareCriteria 取决于参数的类型，而不是其行为。

当您检查对象的类型以选择要具有的行为时，不使用 instanceof 的规则是有效的。显然，该行为属于您检查其类型的不同对象。但在这种情况下，your对象的行为取决于您传入的对象的类型，并且属于调用对象，而不是像以前那样属于被调用对象。这种情况与重写 equals() 时类似。您进行类型检查，以便传入的对象与 this 对象的类型相同，然后实现您的行为：如果测试失败，则返回 false；否则，进行相等测试。

结论：在这种情况下使用 instanceof 是可以的。

这是 Steve Yegge 撰写的一篇较长的文章，我认为它解释得更好，使用一个简单明了的例子。我认为这很适合你的问题。

请记住：多态性是好的，除非它不是。 :)

Answer 5

Smalltalk 的方法是在层次结构中引入更多层。因此 Between 和 greaterThan 将是 rangedCompareCriteria （或其他东西）的子类，并且 rangeCompareCriteria::matchCompareCriteria 将返回 <当被问及自身的两个实例是否具有可比性时，为 true。

说到这里，您可能想将“matchCompareCriteria”重命名为更好地表达意图的名称。