「親x = new Child（）;」ではなく「親x = new Child（）;」は、後者を使用できる場合の悪い習慣ですか？

たとえば、次のようなフラグメントを作成するコードを見たことがあります。

Fragment myFragment=new MyFragment();

MyFragmentではなくFragmentとして変数を宣言します。MyFragmentはFragmentの子クラスです。このコードは次のようにすべきだと思うので、このコード行を満足していません

MyFragment myFragment=new MyFragment();

より具体的ですが、本当ですか？

または質問の一般化では、使用するのは悪い習慣ですか？

Parent x=new Child();

の代わりに

Child x=new Child();

前者をコンパイルエラーなしで後者に変更できるとしたら？

コンテキストに依存しますが、可能な限り最も抽象的な型を宣言する必要があると思います。そうすれば、コードは可能な限り一般的になり、無関係な詳細に依存しません。

例としては、LinkedListとのArrayList両方のがありListます。コードがどの種類のリストでも同じように機能する場合、サブクラスの1つに任意に制限する理由はありません。

JacquesBの答えは正しいですが、少し抽象的です。いくつかの側面をより明確に強調させてください。

コードスニペットでは、newキーワードを明示的に使用します。具体的な型に固有の可能性が高い初期化手順をさらに続行したい場合は、その特定の型で変数を宣言する必要があります。

他のどこかからアイテムを入手する場合、状況は異なりますIFragment fragment = SomeFactory.GiveMeFragments(...);。ここで、ファクトリは通常、可能な限り最も抽象的な型を返す必要があり、下位コードは実装の詳細に依存するべきではありません。

潜在的にパフォーマンスの違いがあります。

派生クラスが封印されている場合、コンパイラは、そうでなければ仮想呼び出しになるものをインライン化し、最適化または削除できます。そのため、パフォーマンスに大きな違いが生じる可能性があります。

例：ToStringは仮想呼び出しですがString、封印されています。でString、ToStringとしてあなたが宣言しそうならば、何もしませんobjectそれは仮想呼び出しだあなたが宣言した場合、Stringクラスが封入されているので、コンパイラは知っていない派生クラスでメソッドをオーバーライドしたことが何-OPませんので、。同様の考慮事項がArrayListvsに適用されますLinkedList。

したがって、オブジェクトの具体的なタイプがわかっている場合（そして、それを隠すカプセル化の理由がない場合）、そのタイプとして宣言する必要があります。オブジェクトを作成したばかりなので、具象型はわかっています。

主な違いは、必要なアクセスのレベルです。そして、抽象化に関するすべての良い答えには動物が関係している、またはそう言われています。

あなたが少数の動物を持っているとしましょう- Cat BirdそしてDog。-今、これらの動物は、いくつかの一般的な行動を持っているmove()、eat()とspeak()。彼らはすべて異なった食事をし、異なった話し方をしますが、私の動物が食べたり話したりする必要がある場合、私は彼らがそれをどうするかをあまり気にしません。

しかし、時々そうします。番犬や番鳥を一生懸命にしたことはありませんが、番犬は飼っています。だから誰かが私の家に侵入したとき、私は話すだけで侵入者を追い払うことはできません。私は本当に私の犬がbarえる必要があります-これは彼の話すこととは異なります。

したがって、侵入者を必要とするコードでは、実際に行う必要があります Dog fido = getDog(); fido.barkMenancingly();

しかし、ほとんどの場合、動物がうそをつく、鳴き声を出す、おやつをつぶやくなどのトリックを喜んで行うことができます。 Animal pet = getAnimal(); pet.speak();

より具体的には、ArrayListにはないメソッドがいくつかありますList。注目すべきは、trimToSize()。現在、99％のケースで、私たちはこれを気にしません。これListは、私たちが気にするほど大きなものではありません。しかし、そうなることもあります。そのため、ときどき、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(); 

本当に悪いオプションの1つは、メソッドがあるParent場合にのみ使用することです。意図を誤って伝えるため、悪いです。ChildDoSomething()

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; DR - 使用Child上のParentローカルスコープで好ましいです。読みやすさだけでなく、オーバーロードされたメソッド解決が適切に機能し、効率的なコンパイルを可能にすることも必要です。

ローカルスコープでは、

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

概念的には、可能な限り多くの型情報を維持することです。にダウングレードする場合Parent、基本的には有用である可能性のある型情報を取り除くだけです。

完全な型情報を保持することには、主に4つの利点があります。

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()呼び出しが最終的にoverrideを返す同じメソッドを呼び出します2。ちょうど、最初のケースでは、正しいメソッドを見つけるための仮想メソッドルックアップがあります。この仮想メソッドのルックアップは、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：プロトタイピングのためのより可変的なプログラムロジック

最初の3つの利点は大きなものでした。これははるかに状況的です。

それでも、他の人がExcelを使用しているようにコードを使用する場合、コードを常に変更しています。多分私達はに固有のメソッドを呼び出す必要はありませんChildで、このコードのバージョンが、我々は、後でコードを再利用したり手直しすることがあります。

強力な型システムの利点は、プログラムロジックに関する特定のメタデータを提供し、可能性をより簡単に明らかにすることです。これは、プロトタイピングに非常に役立つため、可能な限り保管することをお勧めします。

概要

Parentオーバーロードされたメソッド解決を台無しにして、いくつかのコンパイラの最適化を禁止し、リーダーから情報を削除し、コードをくします。

var実際に使用する方法です。素早く、きれいで、パターン化されており、コンパイラとIDEが適切に仕事をするのに役立ちます。

重要：この回答は、ParentvsChild。メソッドのローカルスコープに関するものです。Parentvsの問題はChild、戻り値の型、引数、およびクラスフィールドによって大きく異なります。

与えられた場合parentType foo = new childType1();、コードは上の親型メソッドの使用に制限されますが、のインスタンスだけでなく、型が派生するオブジェクトfooへfooの参照に格納できparentますchildType1。新しいchildType1インスタンスがfoo参照を保持する唯一のものである場合、fooの型をとして宣言する方が適切な場合がありますchildType1。一方、foo他の型への参照を保持する必要がある場合は、宣言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>です。誰かがこのメソッドの結果をに割り当てたい場合Map<K, V>、それを行うことができます。この結果は単なるマップではなく、順序が定義されたマップであることを明確に伝えています。

このメソッドが返されたとしMap<K, V>ます。呼び出し元LinkedHashMap<K, V>がを必要とする場合、型チェック、キャスト、エラー処理を行う必要があり、これは非常に面倒です。