“Çocuk x = yeni Çocuk ();” yerine “Üst x = yeni Çocuk ();”, ikincisini kullanabilirsek kötü bir uygulama mı?

Örneğin, bunun gibi bir parça oluşturan bazı kodlar görmüştüm:

Fragment myFragment=new MyFragment();

bu bir değişkeni MyFragment yerine Fragment olarak bildirir, ki MyFragment bir Fragment alt sınıfıdır. Bu kod satırını karşılamam çünkü bu kodun olması gerektiğini düşünüyorum:

MyFragment myFragment=new MyFragment();

Hangisi daha belirgin, bu doğru mu?

Veya sorunun genelleştirmesinde, kullanımı kötü bir uygulama mıdır:

Parent x=new Child();

yerine

Child x=new Child();

eski olanı derleme hatası olmadan ikincisine çevirebilir miyiz?

Bağlama bağlı, ancak mümkün olan en soyut türü açıklamanız gerektiğini savunuyorum . Bu şekilde kodunuz mümkün olduğu kadar genel olacak ve alakasız ayrıntılara bağlı olmayacaktır.

Bir örnek, her ikisinden de gelen LinkedListve sahip olacaktı . Eğer kod herhangi bir listeyle eşit derecede çalışırsa, keyfi olarak alt sınıflardan birine sınırlamak için bir sebep yoktur.ArrayListList

JacquesB'nin cevabı doğru olsa da, biraz soyut. Bazı yönleri daha net vurgulayayım:

Kod snippet'inizde, newanahtar kelimeyi açıkça kullanırsınız ve belki de somut tür için büyük olasılıkla özel olan başka başlatma adımlarına devam etmek istersiniz: o zaman değişkeni o somut türle belirtmeniz gerekir.

Bu maddeyi başka bir yerden aldığınızda, durum farklı IFragment fragment = SomeFactory.GiveMeFragments(...);. Burada, fabrika normalde mümkün olan en soyut tipi iade etmeli ve aşağı kod uygulama detaylarına bağlı olmamalıdır.

Potansiyel olarak performans farklılıkları vardır.

Eğer türetilmiş sınıf mühürlenirse, derleyici sanal çağrılar ne olabilir diye sıraya sokabilir ve optimize edebilir veya ortadan kaldırabilir. Yani önemli bir performans farkı olabilir.

Örnek: ToStringsanal bir çağrıdır, ancak Stringmühürlenmiştir. Açık String, ToStringno-op, yani objectsanal bir çağrı olduğunu bildirirseniz, bir Stringderleyiciyi ilan ederseniz, türetilmiş bir sınıfın, metodu geçersiz kılmadığını bilir, çünkü sınıf mühürlüdür, yani bu bir no-op'tur. Benzer düşünceler ArrayListvs için de geçerlidir LinkedList.

Bu nedenle, nesnenin somut türünü biliyorsanız (ve onu gizlemek için bir kapsülleme sebebi yoktur), bu tür olarak beyan etmelisiniz. Nesneyi yeni oluşturduğunuzdan, beton türünü biliyorsunuz.

Önemli fark, gereken erişim düzeyidir. Ve soyutlama ile ilgili her iyi cevap hayvanları içerir, ya da bana söylenir.

Farz edelim ki birkaç hayvanınız var - Cat Birdve Dog. Şimdi bu hayvanlar birkaç genel davranışlara sahip - move(), eat()ve speak(). Hepsi farklı yiyorlar ve farklı konuşuyorlar, fakat benim hayvanımı yemek veya konuşmak için ihtiyacım olursa, nasıl yaptıklarını gerçekten umursamıyorum.

Ama bazen yapıyorum. Asla bir bekçi kedisi veya bekçi kuşu istemedim, ama bir bekçi köpeğim var. Birisi evime girdiğinde, davetsiz misafirleri korkutmak için konuşmaya güvenemem. Gerçekten havlamak için köpeğime ihtiyacım var - bu sadece konuşması olan konuşmasından farklı.

Yani bir davetsiz misafir gerektiren kodunda gerçekten yapmam gereken Dog fido = getDog(); fido.barkMenancingly();

Ama çoğu zaman, herhangi bir hayvanın, dokunma, miyavlama veya tweet atmalarının olduğu püf noktaları yapmalarını sağlayabilirim. Animal pet = getAnimal(); pet.speak();

Daha somut olmak için, ArrayList'in yapmayan bazı yöntemleri var List. Özellikle trimToSize(),. Şimdi, vakaların% 99'unda bunu umursamıyoruz. ListBizim bakım için neredeyse hiç büyük yeterlidir. Ama olduğu zamanlar vardır. Bu nedenle, zaman zaman özellikle bir yedekleme dizisini ArrayListyürütmek trimToSize()ve küçültmek için sormamız gerekir .

Bunun yapım aşamasında yapılması gerekmediğine dikkat edin - kesinlikle emin olursak bir geri dönüş yöntemi veya hatta bir döküm ile yapılabilir.

Genel olarak konuşursanız, kullanmalısınız

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

veya

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

yerel değişkenler için, değişkenin başlangıçta başlatıldığı gibi farklı bir tür olması iyi bir neden olmadığı sürece.

(Burada, C ++ kodunun büyük olasılıkla akıllı bir işaretçi kullanması gerektiği gerçeğini görmezden geliyorum. Aslında bilemeyeceğim birden fazla satırın olmadığı ve olmadığı durumlar var.)

Buradaki genel fikir, değişkenlerin otomatik tür algılamasını destekleyen dillerle ilgilidir, kullanımı kodun okunmasını kolaylaştırır ve doğru olanı yapar (yani, derleyicinin tür sistemi mümkün olduğu kadar en iyi duruma getirebilir ve ilklendirmeyi yeni olacak şekilde değiştirebilir) tür, çoğu özet kullanılmış olsaydı da çalışır.

İyi çünkü bu kodu anlamak ve değiştirmek kolay:

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

İyi çünkü niyetini iletiyor:

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

Tamam, çünkü yaygın ve anlaşılması kolaydır:

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

Gerçekten kötü olan bir seçenek, Parentsadece Childbir yöntem varsa kullanmaktır DoSomething(). Kötü çünkü niyetini yanlış iletiyor:

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

Şimdi, sorunun özellikle sorduğu durum hakkında biraz daha ayrıntı verelim:

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

İkinci yarıda bir işlev çağrısı yaparak bunu farklı bir biçimde formatlayalım:

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

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

Bu kısaltılabilir:

FunctionCall(new Child());

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

Burada, WhichTypeişlevin çalışmasına izin veren en temel / soyut tür olması gerektiği (performans kaygıları olmadığı sürece) yaygın olarak kabul edildiğini kabul ediyorum . Bu durumda doğru türünün olacağını Parentfalan Parenttüretilmiştir.

Bu akıl yürütme türü Parent, türü kullanmanın neden iyi bir seçim olduğunu açıklamaktadır, ancak diğer seçimlerin kötü olduğu (havaya girmeyen) havaya girmez.

tl, dr - kullanmaChildüzerindeParentyerel kapsamında tercih edilir. Yalnızca okunabilirliğe yardımcı olmakla kalmaz, aynı zamanda aşırı yüklenmiş yöntem çözünürlüğünün düzgün çalıştığından ve verimli derlemeye olanak sağladığından emin olmak için de gereklidir.

Yerel kapsamda

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

Kavramsal olarak, mümkün olan en fazla bilgiyi sağlamakla ilgilidir. Eğer düşürürsek Parent, aslında sadece yararlı olabilecek tipteki bilgileri çıkartıyoruz.

Tam tip bilgiyi saklamanın dört ana avantajı vardır:

1. Derleyiciye daha fazla bilgi sağlar.
2. Okuyucuya daha fazla bilgi sağlar.
3. Daha temiz, daha standart kod.
4. Program mantığını daha değişken kılar.

Avantaj 1: Derleyiciye daha fazla bilgi

Belirgin tip aşırı yüklenmiş yöntem çözünürlüğünde ve optimizasyonda kullanılır.

Örnek: Aşırı yüklenmiş yöntem çözünürlüğü

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

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

Yukarıdaki örnekte, her iki foo()çağrı da işe yarar , ancak bir durumda daha iyi aşırı yüklenmiş yöntem çözünürlüğünü elde ederiz.

Örnek: Derleyici optimizasyonu

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

Yukarıdaki örnekte, her iki .Foo()çağrı da sonuçta overridegeri dönen aynı yöntemi çağırır 2. Sadece, ilk durumda, doğru yöntemi bulmak için sanal bir yöntem arama var; Bu sanal yöntem arama, bu yöntemden bu yana ikinci durumda gerekli değildir sealed.

Benzer bir örnek teşkil @Ben Kredi onun cevabını .

Avantaj 2: Okuyucuya daha fazla bilgi

Tam tipini bilmek, yani Child, kodu okuyanlara programın ne yaptığını görmeyi kolaylaştıran daha fazla bilgi sağlar.

Elbette, belki de her ikisi için de geçerli olan kod için bir önemi yoktur parent.Foo();ve child.Foo();mantıklıdır, ancak biri kodu ilk defa gören biri için daha fazla bilgi basit olur.

Ayrıca, geliştirme ortamına bağlı olarak, IDE hakkında daha yararlı ipuçları ve meta verilerini sağlayan mümkün olabilir Childdaha Parent.

Avantaj 3: Daha temiz, daha standart kod

Son zamanlarda gördüğüm C # kod örneklerinin çoğu var, bunun için temelde steno olan 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

varBeyanname dışı bir ifadeyi görmek sadece göze çarpıyor; durumsal bir neden varsa, harika, ama aksi takdirde anti-pattern görünüyor.

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

Avantaj 4: Prototipleme için daha değişken program mantığı

İlk üç avantaj, büyük avantajlardı; bu çok daha durumsal.

Yine de, diğerleri gibi kod kullananlar için Excel kullanıyor, kodumuzu sürekli değiştiriyoruz. Belki özgü bir yöntemi çağırmak gerekmez Childiçinde bu kod sürümü, ama biz repurpose veya daha sonra kodu biçim verebilirsiniz.

Güçlü bir tip sistemin avantajı, bize program mantığımız hakkında bazı meta veriler sağlayarak olanakları daha kolay ortaya çıkarmasıdır. Bu prototip yapımında inanılmaz derecede faydalıdır, bu yüzden mümkün olduğunda saklamak en iyisidir.

özet

Kullanılması ParentAşırı yüklü yöntem çözünürlüğü kadar pisliklerimizi, bazı derleyici optimizasyonlar inhibe okuyucudan bilgileri kaldırır ve kod çirkin yapar.

Kullanımı vargerçekten gitmek yoludur. Hızlı, temiz, desenli ve derleyicinin ve IDE'nin işlerini doğru yapmasına yardımcı olur.

Önemli : Bu cevap hakkındadırParentvs.Childbir yöntemin yerel kapsamında. SorunuParentvsChilddönüş türleri, argümanlar ve sınıf alanları için çok farklıdır.

Verilen parentType foo = new childType1();kod, ebeveyn-tipi metotların kullanımı ile sınırlı olacak foo, fakat sadece-değil foo, türünden türetilen herhangi bir nesneye referansta parentsaklanabilecek childType1. Yeni childType1örnek, fooreferans alabilecek tek şeyse , footürünü bildirmek daha iyi olabilir childType1. Öte yandan, foodiğer türlere atıfta bulunulması gerekebilirse, bunu parentTypemümkün kılacak şekilde beyan ettirmek.

Kullanmanızı öneririm

Child x = new Child();

yerine

Parent x = new Child();

İkincisi, eski değil iken bilgi kaybeder.

Eski ile yapabileceğiniz her şeyi yapabilirsiniz, ikincisiyle de yapabilirsiniz ancak bunun tersi mümkün değildir.

İşaretçiyi daha fazla ayrıntılandırmak için, birden fazla kalıtım seviyesine sahip olalım.

Base-> DerivedL1->DerivedL2

Ve new DerivedL2()bir değişkenin sonucunu başlatmak istiyorsunuz . Taban türünü kullanmak, Baseya da seçeneğini kullanma seçeneği sunar DerivedL1.

Kullanabilirsiniz

Base x = new DerivedL2();

veya

DerivedL1 x = new DerivedL2();

Birini diğerine tercih etmenin mantıklı bir yolunu görmüyorum.

Eğer kullanırsan

DerivedL2 x = new DerivedL2();

tartışacak bir şey yok.

Değişkenleri her zaman en spesifik tür olarak döndürmeyi veya saklamayı, ancak parametreleri en geniş tür olarak kabul etmeyi öneririm.

Örneğin

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

Parametreler List<T>çok genel bir türdür. ArrayList<T>, LinkedList<T>Ve diğerleri hepsi bu yöntemle kabul edilebilir.

Önemlisi, dönüş türü LinkedHashMap<K, V>değil Map<K, V>. Birisi bu yöntemin sonucunu a'ya atamak isterse Map<K, V>, bunu yapabilir. Bu sonucun sadece bir haritadan ibaret değil, tanımlanmış bir sıraya sahip bir harita olduğunu açıkça ifade ediyor.

Bu yöntemin geri döndüğünü varsayalım Map<K, V>. Arayan bir kişi LinkedHashMap<K, V>isterse, gerçekten zahmetli olan bir tür kontrol, döküm ve hata işlemesi yapmak zorunda kalacaklardı.