C++和Java在重写方法时支持返回类型协变。
然而，两者都不支持参数类型的逆变 - 而是将其转换为过载（Java）或隐藏（C++）。
为什么会这样呢? 在我看来，允许这种情况并不会有任何问题。我能够在Java中找到一个原因 - 因为它已经有了“选择最具体版本”的重载机制 - 但无法想出C++的原因。
示例（Java）：
class A {
public void f(String s) {…}
}
class B extends A {
public void f(Object o) {…} // Why doesn't this override A.f?
}
关于逆变性的问题
在语言中添加逆变性会带来许多潜在问题或不太干净的解决方案，并且提供的优势很小，因为它可以在没有语言支持的情况下轻松模拟：
struct A {};
struct B : A {};
struct C {
virtual void f( B& );
};
struct D : C {
virtual void f( A& ); // this would be contravariance, but not supported
virtual void f( B& b ) { // [0] manually dispatch and simulate contravariance
D::f( static_cast<A&>(b) );
}
};
通过简单的额外跳转，您可以手动克服不支持逆变的语言的问题。在此示例中，f( A& )无需为虚函数，且调用是完全合格的，以抑制虚分派机制。
这种方法展示了在将逆变添加到没有完全动态分派的语言中时出现的第一个问题之一：
// assuming that contravariance was supported:
struct P {
virtual f( B& );
};
struct Q : P {
virtual f( A& );
};
struct R : Q {
virtual f( ??? & );
};
在逆变性生效的情况下，Q::f 将是 P::f 的重写，对于每个可以作为 P::f 参数的对象 o，该对象同样也是 Q::f 的有效参数。但是，通过在层级结构中添加额外的层级，我们面临着设计问题： R::f(B&) 是否是 P::f 的有效重写，还是应该是 R::f(A&)？
如果没有逆变性，R::f(B&) 明显是 P::f 的重写，因为签名完全匹配。一旦在中间级别加入逆变性，问题在于存在在 Q 级别上有效但在 P 或 R 级别上无效的参数。为了让 R 满足 Q 的要求，唯一的选择是强制签名为 R::f(A&)，以使以下代码能够编译：
int main() {
A a; R r;
Q & q = r;
q.f(a);
}
同时，语言中没有任何阻止以下代码的限制：
struct R : Q {
void f( B& ); // override of Q::f, which is an override of P::f
virtual f( A& ); // I can add this
};
现在我们有一个有趣的效果：
int main() {
R r;
P & p = r;
B b;
r.f( b ); // [1] calls R::f( B& )
p.f( b ); // [2] calls R::f( A& )
}
在[1]中，有一个直接调用R成员方法的调用。由于r是一个局部对象而不是一个引用或指针，因此没有动态分派机制，最佳匹配是R::f( B& )。同时，在[2]中通过基类的引用进行了调用，启用了虚拟分派机制。
R::f( A& )是Q::f( A& )的覆盖，后者又是P::f( B& )的覆盖，因此编译器应该调用R::f( A& )。虽然这在语言中可以完美定义，但是发现两个几乎完全相同的调用[1]和[2]实际上调用了不同的方法可能令人惊讶，而且在[2]中系统会调用一个不是最佳匹配的参数。
当然，也可以有不同的观点： R::f( B& ) 应该是正确的覆盖，而不是R::f( A& )。在这种情况下问题是：
int main() {
A a; R r;
Q & q = r;
q.f( a ); // should this compile? what should it do?
}
Q类，前面的代码是完全正确的：Q::f接受一个A&作为参数。编译器没有理由抱怨那段代码。但问题是，在这个假设下，R::f接受一个B&而不是A&作为参数！实际上，将要被使用的重载并不能处理a参数，即使在调用的地方方法的签名看起来是完全正确的。这条路线导致我们确定第二条路径比第一条更糟糕。R::f(B&)不可能是Q::f(A&)的重载。C::f和D::f都不是覆盖而是具有不同签名的重载。在这两种情况下，它们实际上都是同一个函数名称的重载，唯一的区别是由于C++查找规则，C::f重载将被D::f隐藏。但这仅意味着编译器默认情况下不会找到隐藏的重载，而不是不存在该重载：int main() {
D d; B b;
d.f( b ); // D::f( A& )
d.C::f( b ); // C::f( B& )
}
通过轻微改变类的定义，它可以被制作成与Java完全相同的工作方式：
struct D : C {
using C::f; // Bring all overloads of `f` in `C` into scope here
virtual void f( A& );
};
int main() {
D d; B b;
d.f( b ); // C::f( B& ) since it is a better match than D::f( A& )
}
class A {
public void f(String s) {...}
public void f(Integer i) {...}
}
class B extends A {
public void f(Object o) {...} // Which A.f should this override?
}
对于C++，Stroustrup在《C++的设计与演化》第3.5.3节中简要讨论了隐藏的原因（链接）。他的理由是（我来解释一下），其他解决方案会带来同样多的问题，自从C With Classes时代以来就一直如此。
举个例子，他给出了两个类 - A和B派生类。它们都有一个虚拟的copy()函数，该函数接受其各自类型的指针。如果我们这样说：
A a;
B b;
b.copy( & a );
目前存在错误，因为B的copy()函数覆盖了A的函数。如果没有错误，则只有A的copy()函数才能更新B的A部分。
再次强调，我进行了改述 - 如果您感兴趣，请阅读这本优秀的书籍。
void A::copy(A*)和void B::copy(B*)，并且如果我们有B <: A，那么逆变应该是void B::copy(A*)和void A::copy(B*)。你所描述的是协变，协变在返回类型上是允许的，但在参数类型上是类型不安全的。（虽然我可能搞反了——我有一个倾向于混淆这些内容。但我相当确定。） - Antal Spector-Zabusky虽然这是任何面向对象语言中都很好的功能，但我仍然需要在我的当前工作中找到它的适用性。
也许现在并没有真正需要它。
interface Alpha
interface Beta
interface Gamma extends Alpha, Beta
class A {
public void f(Alpha a)
public void f(Beta b)
}
class B extends A {
public void f(Object o) {
super.f(o); // What happens when o implements Gamma?
}
}
您遇到的问题类似于多重继承不被鼓励的原因。（如果您尝试直接调用 A.f(g)，将会得到一个编译错误。）
super.f(o)应该引发编译时类型错误：可以在静态上下文中确定不存在接受Object参数的super.f方法。（例如，如果调用new B().f("bad")会发生什么？它不仅是模糊的，而且是类型不安全的！）如果您允许无限制地使用super，那么将出现大量类型不安全的程序。但您可以通过参数逆变来实现这一点。 - Antal Spector-Zabuskyclass A {
public void f(String s) {...}
}
class B extends A {
public void f(String s) {...} // this can override A.f
public void f(Object o) {...} // with contra-variance, so can this!
}
现在同一个方法有两个有效的重写：
A a = new B();
a.f(); // which f is called?
除了重载问题，我想不到其他的了。
编辑：我后来找到了这篇C++ FQA条目（20.8），它与上述观点一致——重载的存在为参数逆变性带来了严重问题。
Object的方法覆盖了另一个接受其他参数类型的方法肯定会有问题。另一方面，在某些情况下，明确指定一个编写出来的源代码片段应被视为同时覆盖或实现一个或多个特定基类或接口方法以及实现具有更一般参数类型的新类型可能是有用的。 - supercat