Apakah "Induk x = Anak baru ();" bukannya "Anak x = Anak baru ();" praktik yang buruk jika kita dapat menggunakan yang terakhir?

Sebagai contoh, saya telah melihat beberapa kode yang membuat fragmen seperti ini:

Fragment myFragment=new MyFragment();

yang mendeklarasikan variabel sebagai Fragmen alih-alih MyFragment, yang MyFragment adalah kelas anak dari Fragment. Saya tidak puas dengan baris kode ini karena saya pikir kode ini seharusnya:

MyFragment myFragment=new MyFragment();

mana yang lebih spesifik, apakah itu benar?

Atau dalam generalisasi pertanyaan, apakah praktik yang buruk untuk digunakan:

Parent x=new Child();

dari pada

Child x=new Child();

jika kita dapat mengubah yang sebelumnya menjadi yang terakhir tanpa kompilasi kesalahan?

Tergantung pada konteksnya, tetapi saya berpendapat Anda harus menyatakan jenis yang paling abstrak . Dengan begitu kode Anda akan menjadi se-general mungkin dan tidak bergantung pada detail yang tidak relevan.

Sebuah contoh akan memiliki LinkedListdan ArrayListyang berasal dari keduanya List. Jika kode akan berfungsi sama baiknya dengan daftar jenis apa pun maka tidak ada alasan untuk secara sewenang-wenang membatasi ke salah satu subkelas.

Jawaban JacquesB benar, meskipun sedikit abstrak. Biarkan saya menekankan beberapa aspek dengan lebih jelas:

Dalam cuplikan kode Anda, Anda secara eksplisit menggunakan newkata kunci, dan mungkin Anda ingin melanjutkan dengan langkah-langkah inisialisasi lebih lanjut yang mungkin spesifik untuk jenis beton: maka Anda perlu mendeklarasikan variabel dengan jenis beton tertentu.

Situasinya berbeda ketika Anda mendapatkan item itu dari tempat lain, misalnya IFragment fragment = SomeFactory.GiveMeFragments(...);. Di sini, pabrik biasanya akan mengembalikan jenis yang paling abstrak yang mungkin, dan kode ke bawah tidak boleh bergantung pada detail implementasi.

Ada potensi perbedaan kinerja.

Jika kelas turunan disegel, maka kompiler dapat sebaris dan mengoptimalkan atau menghilangkan apa yang seharusnya panggilan virtual. Jadi bisa ada perbedaan kinerja yang signifikan.

Contoh: ToStringadalah panggilan virtual, tetapi Stringdisegel. Aktif String, ToStringadalah no-op, jadi jika Anda mendeklarasikan sebagai objectpanggilan virtual, jika Anda menyatakan Stringkompiler tahu tidak ada kelas turunan yang menimpa metode karena kelas disegel, maka itu adalah no-op. Pertimbangan serupa berlaku untuk ArrayListvs LinkedList.

Oleh karena itu, jika Anda mengetahui tipe konkret objek, (dan tidak ada alasan enkapsulasi untuk menyembunyikannya), Anda harus mendeklarasikan sebagai tipe itu. Karena Anda baru saja membuat objek, Anda tahu tipe konkret.

Perbedaan utama adalah tingkat akses yang diperlukan. Dan setiap jawaban yang baik tentang abstraksi melibatkan hewan, atau begitulah yang saya katakan.

Biarkan kami mengira Anda memiliki beberapa hewan - Cat Birddan Dog. Sekarang, hewan ini memiliki perilaku umum beberapa - move(), eat(), dan speak(). Mereka semua makan secara berbeda dan berbicara dengan cara yang berbeda, tetapi jika saya membutuhkan hewan saya untuk makan atau berbicara, saya tidak terlalu peduli bagaimana mereka melakukannya.

Tetapi terkadang saya melakukannya. Saya tidak pernah memiliki kucing penjaga atau burung penjaga, tetapi saya memiliki anjing penjaga. Jadi ketika seseorang mendobrak masuk ke rumah saya, saya tidak bisa hanya mengandalkan berbicara untuk menakuti pengganggu. Saya benar-benar membutuhkan anjing saya untuk menggonggong - ini berbeda dari pidatonya, yang hanya guk.

Jadi dalam kode yang membutuhkan penyusup saya benar-benar perlu melakukannya Dog fido = getDog(); fido.barkMenancingly();

Tapi sebagian besar waktu, saya bisa dengan senang hati membuat hewan melakukan trik di mana mereka makan, mengeong atau tweet untuk hadiah. Animal pet = getAnimal(); pet.speak();

Jadi agar lebih konkret, ArrayList memiliki beberapa metode yang Listtidak. Khususnya trimToSize(),. Sekarang, dalam 99% kasus, kami tidak peduli tentang ini. Itu Listhampir tidak pernah cukup besar bagi kita untuk peduli. Tetapi ada saat-saat seperti itu. Jadi kadang-kadang, kita harus secara khusus meminta untuk ArrayListmengeksekusi trimToSize()dan membuat array dukungannya lebih kecil.

Perhatikan bahwa ini tidak harus dilakukan saat konstruksi - itu bisa dilakukan melalui metode pengembalian atau bahkan pemeran jika kami benar-benar yakin.

Secara umum, Anda harus menggunakan

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

atau

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

untuk variabel lokal kecuali ada alasan kuat untuk variabel tersebut memiliki tipe yang berbeda seperti apa yang diinisialisasi dengannya.

(Di sini saya mengabaikan fakta bahwa kode C ++ kemungkinan besar harus menggunakan smart pointer. Ada beberapa kasus yang tidak dan tanpa lebih dari satu baris saya tidak bisa benar-benar tahu.)

Gagasan umum di sini adalah dengan bahasa yang mendukung deteksi tipe variabel otomatis, menggunakannya membuat kode lebih mudah dibaca dan melakukan hal yang benar (yaitu, sistem tipe kompiler dapat mengoptimalkan sebanyak mungkin dan mengubah inisialisasi menjadi yang baru tipe berfungsi juga jika sebagian besar abstrak telah digunakan).

Bagus karena mudah dimengerti dan mudah untuk memodifikasi kode ini:

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

Bagus karena itu menyampaikan maksud:

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

Ok, karena itu umum dan mudah dimengerti:

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

Satu opsi yang benar-benar buruk adalah menggunakan Parentjika hanya Childmemiliki metode DoSomething(). Itu buruk karena itu mengomunikasikan niat salah:

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

Sekarang mari kita uraikan sedikit lebih banyak pada kasus pertanyaan yang secara khusus ditanyakan tentang:

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

Mari kita format ini secara berbeda, dengan membuat panggilan fungsi paruh kedua:

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

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

Ini dapat disingkat menjadi:

FunctionCall(new Child());

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

Di sini, saya menganggap itu diterima secara luas yang WhichTypeseharusnya menjadi tipe paling dasar / abstrak yang memungkinkan fungsi untuk bekerja (kecuali ada masalah kinerja). Dalam hal ini tipe yang tepat adalah salah satu Parent, atau Parentberasal dari sesuatu .

Alur penalaran ini menjelaskan mengapa menggunakan jenis Parentini adalah pilihan yang baik, tetapi itu tidak masuk ke cuaca pilihan lain yang buruk (mereka tidak).

tl; dr - MenggunakanChildlebihParentdisukai dalam lingkup lokal. Ini tidak hanya membantu keterbacaan, tetapi juga perlu untuk memastikan bahwa resolusi metode kelebihan beban bekerja dengan baik dan membantu memungkinkan kompilasi yang efisien.

Dalam lingkup lokal,

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

Secara konseptual, ini tentang menjaga informasi jenis yang paling mungkin. Jika kami menurunkan versi ke Parent, kami pada dasarnya hanya menghapus informasi jenis yang bisa berguna.

Mempertahankan informasi tipe yang lengkap memiliki empat keunggulan utama:

1. Memberikan informasi lebih lanjut kepada kompiler.
2. Memberikan lebih banyak informasi kepada pembaca.
3. Kode lebih bersih dan lebih standar.
4. Membuat logika program lebih bisa berubah.

Keuntungan 1: Informasi lebih lanjut ke kompiler

Jenis yang jelas digunakan dalam resolusi metode kelebihan beban dan optimasi.

Contoh: Resolusi metode kelebihan beban

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

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

Dalam contoh di atas, kedua foo()panggilan berfungsi , tetapi dalam satu kasus, kami mendapatkan resolusi metode kelebihan beban yang lebih baik.

Contoh: Optimasi kompiler

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; }
}

Dalam contoh di atas, kedua .Foo()panggilan pada akhirnya memanggil overridemetode yang sama yang mengembalikan 2. Hanya saja, dalam kasus pertama, ada pencarian metode virtual untuk menemukan metode yang benar; pencarian metode virtual ini tidak diperlukan dalam kasus kedua sejak metode itu sealed.

Kredit untuk @Ben yang memberikan contoh serupa dalam jawabannya .

Keuntungan 2: Informasi lebih lanjut kepada pembaca

Mengetahui jenis yang tepat, yaitu Child, memberikan lebih banyak informasi kepada siapa pun yang membaca kode, sehingga lebih mudah untuk melihat apa yang sedang dilakukan program.

Tentu, mungkin tidak peduli dengan kode aktual karena kedua parent.Foo();dan child.Foo();masuk akal, tapi bagi seseorang melihat kode untuk pertama kalinya, informasi lebih lanjut hanya biasa membantu.

Selain itu, tergantung pada lingkungan pengembangan Anda, IDE mungkin dapat memberikan tooltips lebih bermanfaat dan metadata tentang Childdibanding Parent.

Keuntungan 3: Lebih bersih, kode lebih standar

Sebagian besar contoh kode C # yang saya lihat akhir-akhir ini digunakan var, yang pada dasarnya adalah singkatan 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

Melihat varpernyataan non- deklarasi sama sekali tidak terlihat; jika ada alasan situasional untuk itu, mengagumkan, tetapi sebaliknya itu terlihat anti-pola.

// 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();   

Keuntungan 4: Lebih banyak logika program yang bisa berubah untuk prototyping

Tiga keuntungan pertama adalah yang besar; ini jauh lebih situasional.

Namun, untuk orang yang menggunakan kode seperti orang lain menggunakan Excel, kami terus mengubah kode kami. Mungkin kita tidak perlu memanggil metode unik untuk Childdi ini versi kode, tapi kami mungkin menggunakan kembali atau ulang kode nanti.

Keuntungan dari sistem tipe yang kuat adalah bahwa ia memberi kami meta-data tertentu tentang logika program kami, membuat kemungkinan lebih mudah terlihat. Ini sangat berguna dalam pembuatan prototipe, jadi yang terbaik adalah simpan sedapat mungkin.

Ringkasan

Menggunakan Parentresolusi metode overloaded yang berantakan, menghambat beberapa optimisasi kompiler, menghapus informasi dari pembaca, dan membuat kode lebih jelek.

Menggunakan varbenar-benar cara untuk pergi. Cepat, bersih, berpola, dan membantu kompiler dan IDE untuk melakukan pekerjaan mereka dengan benar.

Penting : Jawaban ini tentangParentvs.Childdalam lingkup lokal metode. MasalahParentvsChildsangat berbeda untuk jenis kembali, argumen, dan bidang kelas.

Diberikan parentType foo = new childType1();, kode akan dibatasi untuk menggunakan metode tipe induk pada foo, tetapi akan dapat menyimpan ke fooreferensi ke objek apa pun yang jenisnya berasal dari - parentbukan hanya contoh childType1. Jika childType1instance baru adalah satu-satunya yang foopernah memiliki referensi, maka mungkin lebih baik untuk menyatakan footipe sebagai childType1. Di sisi lain, jika foomungkin perlu menyimpan referensi ke tipe lain, setelah itu dinyatakan sebagai parentTypeakan memungkinkan.

Saya sarankan menggunakan

Child x = new Child();

dari pada

Parent x = new Child();

Yang terakhir kehilangan informasi sementara yang pertama tidak.

Anda dapat melakukan segalanya dengan yang pertama yang bisa Anda lakukan dengan yang terakhir tetapi tidak sebaliknya.

Untuk menguraikan pointer lebih jauh, mari Anda memiliki beberapa level pewarisan.

Base-> DerivedL1->DerivedL2

Dan Anda ingin menginisialisasi hasil new DerivedL2()ke variabel. Menggunakan tipe dasar memberi Anda pilihan untuk menggunakan Baseatau DerivedL1.

Anda dapat gunakan

Base x = new DerivedL2();

atau

DerivedL1 x = new DerivedL2();

Saya tidak melihat cara logis untuk lebih memilih satu daripada yang lain.

Jika Anda menggunakan

DerivedL2 x = new DerivedL2();

tidak ada yang perlu diperdebatkan.

Saya akan menyarankan selalu mengembalikan atau menyimpan variabel sebagai tipe yang paling spesifik, tetapi menerima parameter sebagai tipe terluas.

Misalnya

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

Parameternya adalah List<T>, tipe yang sangat umum. ArrayList<T>, LinkedList<T>dan yang lainnya semuanya dapat diterima dengan metode ini.

Yang penting, tipe pengembaliannya LinkedHashMap<K, V>bukan Map<K, V>. Jika seseorang ingin menugaskan hasil metode ini ke Map<K, V>, mereka dapat melakukannya. Ini dengan jelas mengomunikasikan bahwa hasil ini lebih dari sekedar peta, tetapi peta dengan urutan yang ditentukan.

Misalkan metode ini dikembalikan Map<K, V>. Jika penelepon menginginkan LinkedHashMap<K, V>, mereka harus melakukan pemeriksaan jenis, pemeran dan penanganan kesalahan, yang benar-benar rumit.