如果可以使用后者，那么“父项x = new Child（）;”而不是“ Child x = new Child（）;”是一种不好的做法吗？

例如，我看过一些代码创建了这样的片段：

Fragment myFragment=new MyFragment();

它声明一个变量为Fragment而不是MyFragment，MyFragment是Fragment的子类。我对这行代码不满意，因为我认为该代码应为：

MyFragment myFragment=new MyFragment();

哪个更具体，是真的吗？

还是概括地说，使用以下做法是错误的做法：

Parent x=new Child();

代替

Child x=new Child();

是否可以在没有编译错误的情况下将前一个更改为后一个？

这取决于上下文，但是我认为您应该声明尽可能抽象的类型。这样，您的代码将尽可能通用，而不依赖无关的细节。

一个例子是有一个LinkedList和ArrayList都来自List。如果代码在任何类型的列表中都能很好地工作，则没有理由将其任意地限制在一个子类中。

JacquesB的回答是正确的，尽管有点抽象。让我更清楚地强调一些方面：

在代码段中，您明确地使用了new关键字，也许您想继续执行可能针对具体类型的进一步初始化步骤：然后，您需要使用该具体类型声明变量。

当您从其他地方获得该商品时，情况就不同了IFragment fragment = SomeFactory.GiveMeFragments(...);。在这里，工厂通常应返回最抽象的类型，而向下的代码不应依赖于实现细节。

可能存在性能差异。

如果派生类是密封的，则编译器可以内联并优化或消除虚拟调用。因此，可能会有明显的性能差异。

示例：ToString是一个虚拟呼叫，但String被密封。上String，ToString是一个空操作，所以如果你声明为object这是一个虚拟的电话，如果声明一个String编译器知道没有派生类覆盖的方法，因为类是密封的，所以这是一个无操作。类似的考虑适用于ArrayListVS LinkedList。

因此，如果您知道对象的具体类型（并且没有隐藏它的封装原因），则应声明为该类型。由于您刚刚创建了对象，因此知道具体类型。

关键区别在于所需的访问级别。关于抽象的每个好的答案都涉及动物，或者有人告诉我。

让我们假设您有一些动物- Cat Bird和Dog。现在，这些动物有几个常见的行为- move()，eat()和speak()。他们的饮食不同，说话也不同，但是如果我需要我的动物吃饭或说话，我并不在乎他们如何做。

但是有时候我会。我从来没有用过护卫猫或护卫鸟，但我确实有护卫犬。因此，当有人闯入我的房子时，我不能仅仅依靠说话来吓跑入侵者。我真的需要我的狗吠叫-这和他的说话不同，那只是一声。

所以在需要入侵者的代码中，我真的需要做 Dog fido = getDog(); fido.barkMenancingly();

但是大多数时候，我可以很高兴地让任何动物在招呼，喵喵叫或鸣叫以求佳节时招人喜欢。 Animal pet = getAnimal(); pet.speak();

因此，更具体地说，ArrayList有一些List没有的方法。值得注意的是trimToSize()。现在，在99％的情况下，我们对此并不关心。的List是几乎没有大的足以让我们不在乎。但是有时候是这样。因此，有时候，我们必须专门要求an ArrayList执行trimToSize()并使其后备数组变小。

请注意，这不是必须在构造时进行的-如果我们绝对确定，则可以通过return方法甚至是强制转换来完成。

一般来说，您应该使用

var x = new Child(); // C#

要么

auto x = new Child(); // C++

对于局部变量，除非有充分的理由使变量的类型与初始化时的类型不同。

（在这里，我忽略了以下事实：C ++代码很可能应该使用智能指针。在某些情况下，我实际上不知道或不超过一行。）

这里的总体思想是使用支持变量的自动类型检测的语言，使用它可以使代码更易于阅读并且可以执行正确的操作（也就是说，编译器的类型系统可以尽可能地优化并将初始化更改为新的如果使用了大多数抽象，则类型也可以使用）。

很好，因为它易于理解并且易于修改此代码：

var x = new Child(); 
x.DoSomething();

很好，因为它传达了意图：

Parent x = new Child(); 
x.DoSomething(); 

好的，因为它是常见且易于理解的：

Child x = new Child(); 
x.DoSomething(); 

真正糟糕的一个选择是使用Parent只有Child一种方法DoSomething()。这很糟糕，因为它错误传达了意图：

Parent x = new Child(); 
(x as Child).DoSomething(); // DON'T DO THIS! IF YOU WANT x AS CHILD, STORE x AS CHILD

现在，让我们详细说明该问题专门询问的情况：

Parent x = new Child(); 
x.DoSomething(); 

让我们将后半部分作为函数调用，以不同的方式设置此格式：

WhichType x = new Child(); 
FunctionCall(x);

void FunctionCall(WhichType x)
    x.DoSomething(); 

可以简化为：

FunctionCall(new Child());

void FunctionCall(WhichType x)
    x.DoSomething();

在这里，我认为它WhichType应该是使函数正常工作的最基本/最抽象的类型（除非存在性能问题），这已被广泛接受。在这种情况下，正确的类型应该是Parent或Parent从中派生出。

这条推理路线说明了为什么使用类型Parent是一个不错的选择，但是不会因其他选择不好（它们不是）而陷入困境。

TL;博士 - 使用Child以上Parent是在局部范围内是优选的。它不仅有助于提高可读性，而且还必须确保重载的方法解析正常工作并有助于实现高效的编译。

在当地范围内

Parent obj = new Child();  // Works
Child  obj = new Child();  // Better
var    obj = new Child();  // Best

从概念上讲，它与维护尽可能多的类型信息有关。如果我们降级到Parent，我们实际上只是在剥离可能有用的类型信息。

保留完整的类型信息具有四个主要优点：

1. 向编译器提供更多信息。
2. 向读者提供更多信息。
3. 更干净，更标准化的代码。
4. 使程序逻辑更易变。

优势1：向编译器提供更多信息

表观类型用于重载方法解析和优化中。

示例：重载的方法解析

main()
{
    Parent parent = new Child();
    foo(parent);

    Child  child  = new Child();
    foo(child);
}
foo(Parent arg) { /* ... */ }  // More general
foo(Child  arg) { /* ... */ }  // Case-specific optimizations

在上面的示例中，两个foo()调用均有效，但在一种情况下，我们获得了更好的重载方法解析。

示例：编译器优化

main()
{
    Parent parent = new Child();
    var x = parent.Foo();

    Child  child  = new Child();
    var y = child .Foo();
}
class Parent
{
    virtual         int Foo() { return 1; }
}
class Child : Parent
{
    sealed override int Foo() { return 2; }
}

在上面的示例中，两个.Foo()调用最终都调用了return的相同override方法2。只是，在第一种情况下，有一个虚拟方法查找来找到正确的方法。在第二种情况下不需要此虚拟方法查找，因为该方法的sealed。

感谢@Ben，他在回答中提供了类似的示例。

优势2：给读者更多信息

知道确切的类型（即）Child，可以为正在阅读代码的任何人提供更多信息，从而使查看程序的工作变得更加容易。

当然，也许这并不重要，因为无论是实际的代码parent.Foo();和child.Foo();有意义，但对于某人来说看到的第一次代码的详细信息，只是普通的帮助。

此外，根据您的开发环境，IDE可能会提供Child比以下工具更有用的工具提示和元数据：Parent。

优势3：更清洁，更标准化的代码

我最近看到的大多数C＃代码例子，var基本上是简写Child。

Parent obj = new Child();  // Sub-optimal
Child  obj = new Child();  // Optimal, but anti-pattern syntax
var    obj = new Child();  // Optimal, clean, patterned syntax "everyone" uses now

看到一个非var声明语句看起来很像。如果有某种情况下的原因，那太棒了，但否则看起来是反模式的。

// Clean:
var foo1 = new Person();
var foo2 = new Job();
var foo3 = new Residence();

// Staggered:
Person foo1 = new Person();
Job foo2 = new Job();
Residence foo3 = new Residence();   

优势4：更具可变性的原型程序逻辑

前三个优势是最大的优势。这是更多的情况。

不过，对于像其他人一样使用代码的人也使用Excel，我们会不断更改代码。也许我们不需要Child在此版本的代码中调用唯一的方法，但是稍后我们可能会重新使用代码或重新编写代码。

强类型系统的优点在于，它为我们提供了有关程序逻辑的某些元数据，从而使可能性更加明显。这在原型制作中非常有用，因此最好将其保留在尽可能的位置。

摘要

使用Parent混乱的重载方法分辨率，会抑制某些编译器优化，从读取器中删除信息，并使代码更丑陋。

使用var确实是必经之路。它快速，干净，有模式，可帮助编译器和IDE正确完成其工作。

重要提示：这个答案是关于Parent对Child在方法的局部范围。对于返回类型，参数和类字段，Parentvs。的问题Child非常不同。

给定的是parentType foo = new childType1();，代码将仅限于在上使用父类型方法foo，但将能够存储foo对类型源自于的任何对象的引用，parent而不仅仅是对象的实例childType1。如果新childType1实例是唯一foo拥有引用的对象，则最好将foo类型声明为childType1。另一方面，如果foo可能需要保留对其他类型的引用，则将其声明为as parentType将使之成为可能。

我建议使用

Child x = new Child();

代替

Parent x = new Child();

后者会丢失信息，而前者则不会。

您可以使用前者来做所有事情，而可以使用后者来做，反之则不行。

为了进一步详细说明指针，让我们拥有多个继承级别。

Base -> DerivedL1 ->DerivedL2

您想将的结果初始化new DerivedL2()为变量。使用基本类型使您可以选择使用Base或DerivedL1。

您可以使用

Base x = new DerivedL2();

要么

DerivedL1 x = new DerivedL2();

我看不出有任何一种逻辑方法可以优先选择一种方法。

如果您使用

DerivedL2 x = new DerivedL2();

没有什么可争论的。

我建议始终将变量返回或存储为最特定的类型，但接受参数作为最广泛的类型。

例如

<K, V> LinkedHashMap<K, V> keyValuePairsToMap(List<K> keys, List<V> values) {
   //...
}

参数是List<T>，是非常通用的类型。ArrayList<T>，LinkedList<T>其他都可以被此方法接受。

重要的是LinkedHashMap<K, V>，返回类型不是Map<K, V>。如果有人想将此方法的结果分配给a Map<K, V>，他们可以这样做。它清楚地表明，此结果不仅仅是一张地图，而是一张具有定义顺序的地图。

假设此方法返回了Map<K, V>。如果调用者想要a LinkedHashMap<K, V>，则必须进行类型检查，强制转换和错误处理，这确实很麻烦。