Programlarımı planlarken, genellikle şöyle bir düşünce zinciriyle başlarım:

Bir futbol takımı sadece futbolcuların bir listesidir. Bu nedenle, şunu temsil etmeliyim:

var football_team = new List<FootballPlayer>();

Bu listenin sıralaması, oyuncuların kadroda listelendiği sırayı temsil eder.

Ancak daha sonra, takımların sadece oyuncu listesinin yanı sıra kaydedilmesi gereken başka özellikleri de olduğunu fark ediyorum. Örneğin, bu sezonun toplam skoru, mevcut bütçe, tekdüze renkler, stringtakımın adını temsil eden, vb.

Sonra düşünüyorum:

Tamam, bir futbol takımı sadece bir oyuncu listesi gibidir, ancak ek olarak, bir adı (a string) ve çalışan toplam skorları (an int) vardır. .NET, futbol takımlarını saklamak için bir sınıf sağlamaz, bu yüzden kendi sınıfımı yapacağım. En benzer ve ilgili mevcut yapı List<FootballPlayer>, bu yüzden miras alacağım:

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

Ancak bir kılavuzun miras kalmamanız gerektiğini söylediğiList<T> ortaya çıkıyor . Bu rehberle iki açıdan tamamen kafam karıştı.

Neden olmasın?

Görünüşe göre Listperformans için bir şekilde optimize edilmiştir . Nasıl yani? Genişletirsem hangi performans sorunlarına neden olurum List? Tam olarak ne kırılacak?

Gördüğüm başka bir neden List, Microsoft tarafından sağlanan ve üzerinde herhangi bir kontrole sahip değilim , bu yüzden bir "genel API" açtıktan sonra daha sonra değiştiremiyorum . Ama bunu anlamak için mücadele ediyorum. Herkese açık bir API nedir ve neden ilgilenmeliyim? Şu anki projemde bu herkese açık API bulunmuyorsa ve bu olasılığa sahip değilse, bu kılavuzu göz ardı edebilir miyim? Eğer miras alırsamList ve genel bir API'ya ihtiyacım olduğu ortaya çıkarsa, ne tür zorluklar yaşayacağım?

Neden önemli? Liste bir listedir. Ne değişebilirdi? Neyi değiştirmek isteyebilirim?

Ve son olarak, Microsoft benim miras almamı istemiyorsa List, neden sınıfı yapmadılarsealed ?

Başka ne kullanmam gerekiyor?

Görünüşe göre, özel koleksiyonlar için Microsoft, Collectionbunun yerine genişletilmesi gereken bir sınıf sağlamıştır List. Ancak bu sınıf çok çıplaktır ve örneğinAddRange , pek çok yararlı şeyi yoktur . jvitor83'ün cevabı , bu belirli yöntem için bir performans mantığı sağlar, ancak bir yavaş nasıl hayırdanAddRange daha iyi değil AddRange?

Devralmak, Collectiondevralmaktan çok daha fazla iştir Listve hiçbir fayda görmüyorum. Şüphesiz Microsoft bana hiçbir sebepten ötürü fazladan iş yapmamı söylemedi, bu yüzden bir şekilde bir şeyi yanlış anlıyormuşum gibi hissetmeme yardım edemiyorum ve kalıtım Collectionaslında problemim için doğru çözüm değil.

Uygulama gibi öneriler gördüm IList. Sadece hayır. Bu bana hiçbir şey kazandıran düzinelerce boyunda kod satırı.

Son olarak, bazıları bir Listşeye sarmayı önerir :

class FootballTeam 
{ 
    public List<FootballPlayer> Players; 
}

Bununla birlikte iki tane sorun var:

1. Kodumu gereksiz yere ayrıntılı yapar. Şimdi my_team.Players.Countsadece yerine çağırmalıyım my_team.Count. Neyse ki, C # ile indekslemeyi şeffaf hale getirmek ve dahili tüm yöntemleri iletmek için indeksleyicileri tanımlayabilirim List... Ama bu çok fazla kod! Tüm bu işler için ne alacağım?

2. Sadece sade bir anlam ifade etmiyor. Bir futbol takımının oyuncu listesi "yoktur". Bu ise oyuncuların listesi. "John McFootballer SomeTeam oyuncularına katıldı" demiyorsunuz. "John SomeTeam'e katıldı" diyorsunuz. "Bir dizenin karakterlerine" bir harf eklemezsiniz, bir dizeye bir harf eklersiniz. Bir kitaplığın kitaplarına kitap eklemezsiniz, kitaplığa bir kitap eklersiniz.

"Kaputun altında" olan şeyin "Y'nin iç listesine X eklenmesi" olduğu söylenebilir, ancak bu dünya hakkında oldukça sezgisel bir düşünme yolu gibi görünüyor.

Sorum (özetlendi)

"Mantıksal" ( "insan beynine" demek olduğunu) sadece bir veri yapısını temsil doğru C # yolu nedir listait thingsbirkaç çan ve ıslık ile?

Her List<T>zaman kabul edilemez mi? Ne zaman kabul edilebilir? Neden / neden olmasın? Bir programcı, miras alıp almamaya karar verirken neleri dikkate almalıdır List<T>?

Burada bazı iyi cevaplar var. Onlara aşağıdaki noktaları eklerdim.

"Mantıksal" (yani "insan zihnine") sadece birkaç çan ve ıslık olan şeylerin bir listesi olan bir veri yapısını temsil etmenin doğru C # yolu nedir?

Futbolun varlığını bilen bilgisayar programcısı olmayan on kişiden boş alanı doldurmasını isteyin:

Bir futbol takımı _____________

Did kimse diyelim "Birkaç çan ve ıslık ile futbolcuların listesi" ya hepsi diyelim "spor takımı" veya "kulüp" ya da "örgüt" mi? Bir futbol takımının belirli bir tür oyuncu listesi olduğu fikriniz sadece sizin ve sadece sizin zihninizde.

List<T>bir mekanizmadır . Futbol takımı bir iş nesnesidir - yani, programın ticari alanındaki bazı kavramları temsil eden bir nesnedir . Bunları karıştırmayın! Bir futbol takımı bir tür takımdır; o bir sahip bir liste, liste oyuncuların listesidir . Liste belirli bir oyuncu listesi değildir . Bir liste olduğu oyuncuların listesi. Yani adlı bir özellik yapmak Rosterbir olduğunu List<Player>. Ve ReadOnlyList<Player>bir futbol takımını bilen herkesin oyuncuları listeden silebileceğine inanmadığınız sürece bunu yapın.

Her List<T>zaman kabul edilemez mi?

Kime kabul edilemez? Ben mi? Hayır.

Ne zaman kabul edilebilir?

Eğer bir mekanizma bina yapıyorsanız uzanır List<T>mekanizması .

Bir programcı, miras alıp almamaya karar verirken neleri dikkate almalıdır List<T>?

Bir mekanizma mı yoksa bir iş nesnesi mi oluşturuyorum?

Ama bu çok fazla kod! Tüm bu işler için ne alacağım?

List<T>Elli kez üzerinden ilgili üyeler için yönlendirme yöntemleri yazmanızın isteneceği sorunuzu yazmak için daha fazla zaman harcadınız . Açık bir şekilde ayrıntıdan korkmuyorsunuz ve burada çok az miktarda koddan bahsediyoruz; bu birkaç dakikalık bir çalışmadır.

GÜNCELLEME

Biraz daha düşündüm ve bir futbol takımını oyuncu listesi olarak modellememenin bir başka nedeni daha var. Aslında bir futbol takımını oyuncuların bir listesine sahip olarak modellemek kötü bir fikir olabilir . Bir takımın bir oyuncu listesi olması / sahip olması sorunu, sahip olduğunuz şeyin takımın bir anda anlık görüntüsü olmasıdır . Bu sınıf için iş durumunuzun ne olduğunu bilmiyorum, ancak bir futbol takımını temsil eden bir sınıfım olsaydı, "2003 ve 2013 arasında kaç Seahawks oyuncusu sakatlık nedeniyle oyunları kaçırdı?" ya da "Daha önce başka bir takımda oynayan Denver oyuncuları geçen yıla göre en büyük artışı gerçekleştirdi?" veya " Piggers bu yıl sonuna kadar gitti mi? "

Beni sıra modellenecek olduğunu, bir futbol takımı gibi görünüyor tarihsel gerçekler bütünü böyle önden ve- bir oyuncu geçerli oynatıcı liste muhtemelen olmalıdır önemli bir olgudur Açıkçası vb emekli, işe yaralandı olduğu gibi ancak bu nesne ile daha tarihsel bir perspektif gerektiren başka ilginç şeyler olabilir.

Vay canına, yayınınızda birçok soru ve puan var. Microsoft'tan aldığınız nedenlerin çoğu tam olarak yerinde. Hakkında her şeyle başlayalımList<T>

• List<T> son derece optimize edilmiştir. Ana kullanımı bir nesnenin özel bir üyesi olarak kullanılmalıdır.
• Bazen bir dostça adı olan bir sınıf oluşturmak isteyebilirsiniz çünkü Microsoft mühürlerim vermedi: class MyList<T, TX> : List<CustomObject<T, Something<TX>> { ... }. Şimdi yapmak kadar kolay var list = new MyList<int, string>();.
• CA1002: Genel listeleri ortaya koymayın : Temel olarak, bu uygulamayı tek geliştirici olarak kullanmayı planlasanız bile, iyi kodlama uygulamaları ile geliştirilmeye değer, böylece size ve ikinci doğaya aşılanırlar. IList<T>Dizine eklenmiş bir listeye sahip olmak için herhangi bir tüketiciye ihtiyacınız varsa , listeyi yine de gösterebilirsiniz . Bu, daha sonra bir sınıf içindeki uygulamayı değiştirmenizi sağlar.
• Microsoft Collection<T>genel bir kavram olduğu için çok genel bir isim yaptı ... isim her şeyi söylüyor; sadece bir koleksiyon. Gibi daha hassas versiyonu vardır SortedCollection<T>, ObservableCollection<T>, ReadOnlyCollection<T>uygulamak her biri, vb IList<T>ama değil List<T> .
• Collection<T>üyelerin (örn. Ekle, Kaldır vb.) sanal oldukları için geçersiz kılınmasına olanak tanır. List<T>değil.
• Sorunuzun son kısmı açık. Bir Futbol takımı sadece bir oyuncu listesinden daha fazlasıdır, bu yüzden o oyuncu listesini içeren bir sınıf olmalıdır. Kompozisyon ve Miras düşünün . Bir Futbol takımı vardır oyuncuların bir listesini (bir liste), bu oyuncuların listesi değildir.

Bu kodu yazıyorsanız sınıf muhtemelen böyle bir şey olurdu:

public class FootballTeam
{
    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    // Yes. I used LINQ here. This is so I don't have to worry about
    // _roster.Length vs _roster.Count vs anything else.
    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal;
}

Önceki kod şu anlama gelir: sokaktan futbol oynayan bir grup adam ve bir isimleri var. Gibi bir şey:

Her neyse, bu kod (cevabımdan)

public class FootballTeam
{
    // A team's name
    public string TeamName; 

    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

Araçlar: Bu, yönetimi, oyuncuları, yöneticileri vb. Olan bir futbol takımıdır.

Mantığınız resimlerde böyle sunuluyor…

Bu, bileşime ve mirasa klasik bir örnektir .

Bu özel durumda:

Takım, davranış eklenmiş oyuncuların bir listesi mi

veya

Takım, oyuncuların listesini içeren kendine ait bir nesne mi?

Listeyi genişleterek kendinizi çeşitli yollarla sınırlandırmış olursunuz:

1. Erişimi kısıtlayamazsınız (örneğin, listeyi değiştiren kişileri durdurma). İster ihtiyacınız olsun ister istemeyin, tüm Liste yöntemlerini alırsınız.

2. Başka şeylerin listelerini de almak istiyorsanız ne olur? Örneğin, takımların koçları, yöneticileri, taraftarları, ekipmanları vb. Vardır. Bunlardan bazıları kendi başlarına listeler olabilir.

3. Kalıtım seçeneklerinizi sınırlarsınız. Örneğin, genel bir Team nesnesi oluşturmak ve daha sonra bundan devralan BaseballTeam, FootballTeam vb. Listeden miras almak için Team'den miras almanız gerekir, ancak bu, tüm çeşitli takım türlerinin aynı kadroyu aynı şekilde uygulamaya zorlandığı anlamına gelir.

Kompozisyon - nesnenizin içinde istediğiniz davranışı veren bir nesne dahil.

Kalıtım - nesneniz, istediğiniz davranışa sahip nesnenin bir örneği olur.

Her ikisinin de kullanımları vardır, ancak bu bileşimin tercih edildiği açık bir durumdur.

Herkesin işaret ettiği gibi, bir oyuncu takımı bir oyuncu listesi değildir. Bu hata her yerde, belki de çeşitli uzmanlık seviyelerinde birçok insan tarafından yapılır. Çoğu zaman, bu durumda olduğu gibi, sorun ince ve bazen çok iğrençtir. Bu tür tasarımlar kötü çünkü bunlar Liskov İkame İlkesini ihlal ediyor . İnternette bu kavramı açıklayan birçok iyi makale bulunmaktadır; örneğin, http://en.wikipedia.org/wiki/Liskov_substitution_principle

Özetle, sınıflar arasında bir Ebeveyn / Çocuk ilişkisinde korunması gereken iki kural vardır:

• bir Çocuk, Ebeveyn'i tamamen tanımlayandan daha az karakteristik gerektirmemelidir.
• bir Ebeveyn, Çocuğu tamamen tanımlayana ek olarak herhangi bir özellik gerektirmemelidir.

Başka bir deyişle, bir Ebeveyn bir çocuğun gerekli bir tanımıdır ve bir çocuk bir Ebeveynin yeterli bir tanımıdır.

İşte bir çözüm üzerinden düşünmek ve böyle bir hatadan kaçınmaya yardımcı olacak yukarıdaki prensibi uygulamak için bir yol. Bir üst sınıfın tüm işlemlerinin türetilmiş sınıf için hem yapısal hem de anlamsal olarak geçerli olup olmadığını doğrulayarak, kişi hipotezini test etmeliyiz.

• Bir futbol takımı futbolcuların bir listesi midir? (Bir listenin tüm özellikleri aynı anlamda bir ekibe uygulanır mı?)
  • Bir ekip homojen varlıklardan oluşan bir koleksiyon mu? Evet, takım bir Oyuncu topluluğudur
  • Oyuncuların dahil olma sırası takımın durumunu tanımlayıcı mı ve takım açıkça değiştirilmedikçe sıralamanın korunmasını sağlıyor mu? Hayır ve Hayır
  • Oyuncuların takımdaki sıralı konumlarına göre dahil edilmesi / düşürülmesi bekleniyor mu? Hayır

Gördüğünüz gibi, bir listenin yalnızca ilk özelliği bir ekibe uygulanabilir. Dolayısıyla bir takım liste değildir. Liste, takımınızı nasıl yönettiğinizin uygulama ayrıntısı olacaktır, bu nedenle yalnızca oyuncu nesnelerini depolamak ve Team sınıfı yöntemleriyle manipüle etmek için kullanılmalıdır.

Bu noktada, bir Takım sınıfının, bence, bir Liste kullanılarak uygulanmaması gerektiğini belirtmek isterim; çoğu durumda bir Set data yapısı (örneğin HashSet) kullanılarak uygulanmalıdır.

Ya FootballTeamana ekiple birlikte yedek ekip varsa ?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
}

Bunu nasıl modellersiniz?

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

İlişki açıkça bir ve değil a .

veya RetiredPlayers?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
    List<FootballPlayer> RetiredPlayers { get; set; }
}

Genel bir kural olarak, bir koleksiyondan devralmak istiyorsanız, sınıfı adlandırın SomethingCollection.

Senin mu SomethingCollectionsemantik mantıklı? Bunu yalnızca türünüz bir koleksiyonsa yapın Something.

Durumunda FootballTeamkulağa doğru gelmiyor. A Team, a'dan daha fazlasıdır Collection. A Team, diğer cevapların işaret ettiği gibi antrenörler, eğitmenler vb.

FootballCollectionfutbol topluluğuna veya belki de futbol gereçlerinin topluluğuna benziyor. TeamCollection, ekiplerden oluşan bir koleksiyon.

FootballPlayerCollectionList<FootballPlayer>gerçekten yapmak istediğinizde miras kalan bir sınıf için geçerli bir isim olacak bir oyuncu koleksiyonu gibi geliyor .

Gerçekten mi List<FootballPlayer> başa çıkmak için mükemmel bir türüdür. Belki IList<FootballPlayer>bir yöntemle iade ediyorsanız.

Özetle

Kendine sor

1. Mı X bir Y? ya Has X aY ?

2. Sınıf isimlerim ne oldukları anlamına mı geliyor?

Tasarım> Uygulama

Hangi yöntemleri ve özellikleri ortaya koyduğunuz bir tasarım kararıdır. Hangi temel sınıfı devralmış olduğunuz bir uygulama ayrıntısıdır. Birincisine geri adım atmaya değdiğini hissediyorum.

Nesne, veri ve davranışın bir koleksiyonudur.

Yani ilk sorularınız:

• Bu nesne oluşturduğum modelde hangi verileri içeriyor?
• Bu nesne bu modelde hangi davranışı sergiliyor?
• Bu gelecekte nasıl değişebilir?

Kalıtımın "isa" (a) ilişkisi olduğunu, kompozisyonun ise "hasa" ilişkisi olduğunu ima ettiğini unutmayın. Uygulamanız geliştikçe işlerin nereye gidebileceğini göz önünde bulundurarak durumunuz için doğru olanı seçin.

Somut tiplerde düşünmeden önce arayüzlerde düşünmeyi düşünün, çünkü bazı insanlar beynini bu şekilde "tasarım moduna" koymayı daha kolay buluyorlar.

Bu, günlük kodlamada herkesin bilinçli olarak bu seviyede yaptığı bir şey değildir. Ancak bu tür bir konuyu düşünüyorsanız, tasarım sularına giriyorsunuz. Bunun farkında olmak özgürleştirici olabilir.

Tasarım Özelliklerini Göz önünde bulundurun

MSDN veya Visual Studio'da <T> ve IList <T> Listelerine göz atın. Hangi yöntemleri ve özellikleri gösterdiklerine bakın. Bu yöntemlerin hepsi sizin görüşünüze göre birinin FootballTeam'e yapmak isteyeceği bir şey gibi mi gözüküyor?

FootballTeam.Reverse () size mantıklı geliyor mu? FootballTeam.ConvertAll <TOutput> () istediğiniz bir şeye benziyor mu?

Bu hileli bir soru değil; cevap gerçekten "evet" olabilir. <Player> Listesini veya IList <Player> Listesini uygular / devralırsanız, bunlara takılı kalırsınız; modeliniz için idealse, yapın.

Evet'e karar verirseniz, bu mantıklıdır ve nesnenizin bir koleksiyon / oyuncu listesi (davranış) olarak ele alınmasını istersiniz ve bu nedenle ICollection veya IList'i uygulamak istersiniz, bunu yapın. notionally:

class FootballTeam : ... ICollection<Player>
{
    ...
}

Nesnenin bir koleksiyon / oyuncu listesi (veri) içermesini ve bu nedenle koleksiyonun veya listenin bir mülk veya üye olmasını istiyorsanız, elbette bunu yapın. notionally:

class FootballTeam ...
{
    public ICollection<Player> Players { get { ... } }
}

İnsanların saymak, onlara eklemek veya kaldırmak yerine sadece oyuncu setini numaralandırmasını istediğinizi düşünebilirsiniz. IEnumerable <Player> dikkate alınması gereken mükemmel bir seçenektir.

Bu arayüzlerin hiçbirinin modelinizde hiç kullanışlı olmadığını düşünebilirsiniz. Bu daha az olasıdır (IEnumerable <T> birçok durumda yararlıdır) ancak yine de mümkündür.

Size bunlardan birinin her durumda kategorik ve kesin olarak yanlış olduğunu söylemeye çalışan herkes yanlış yönlendirilir. Size bunu söylemeye çalışan herkes , her durumda kategorik ve kesin olarak doğrudur .

Uygulamaya Geç

Veri ve davranışa karar verdikten sonra, uygulama hakkında bir karar verebilirsiniz. Bu, kalıtım veya kompozisyon yoluyla hangi somut sınıflara bağımlı olduğunuzu içerir.

Bu büyük bir adım olmayabilir ve insanlar genellikle kafanızda bir veya iki saniyede geçmek ve yazmaya başlamak mümkün olduğundan tasarım ve uygulamayı birbirine bağlar.

Düşünce Deneyi

Yapay bir örnek: diğerlerinin de belirttiği gibi, bir takım her zaman sadece bir oyuncu topluluğu değildir. Takım için bir maç skorları koleksiyonu tutuyor musunuz? Takım, modelinizle kulüple değiştirilebilir mi? Eğer öyleyse ve takımınız bir oyuncu koleksiyonuysa, belki de bir personel koleksiyonu ve / veya bir puanlar topluluğudur. Sonra ile sonuçlanır:

class FootballTeam : ... ICollection<Player>, 
                         ICollection<StaffMember>,
                         ICollection<Score>
{
    ....
}

Tasarım, buna rağmen, C # 'da bu noktada, <T> Listesinden devralınarak bunları uygulayamazsınız, çünkü C # "yalnızca" tek mirası destekler. (Bu malarky'yi C ++ 'da denediyseniz, bunu iyi bir şey olarak düşünebilirsiniz.) Bir koleksiyonu miras yoluyla ve bir koleksiyonu kompozisyon yoluyla uygulamak muhtemelen kirli hissedecektir . Ve ILIst <Player> .Count ve IList <StaffMember> .Count vb. Uygulamalarını açıkça uygulamadığınız sürece Count gibi özellikler kullanıcılar için kafa karıştırıcı hale gelir ve sonra kafa karıştırıcı olmaktan ziyade sadece acı verir. Bunun nereye gittiğini görebilirsiniz; bağırsak hissi bu caddeyi düşünürken size bu yönde gitmenin yanlış hissettirdiğini söyleyebilir (ve doğru veya yanlış, meslektaşlarınız da bu şekilde uyguladıysanız!)

Kısa Cevap (Çok Geç)

Koleksiyon sınıflarından miras almamaya ilişkin kılavuz C # 'a özgü değildir, bunu birçok programlama dilinde bulabilirsiniz. Kanuna değil, bilgeliğe kavuşur. Bunun bir nedeni, pratikte kompozisyonun anlaşılabilirlik, uygulanabilirlik ve sürdürülebilirlik açısından kalıtımdan sık sık kazandığı düşünülmektedir. Özetle derinlemesine olmadığınız sürece, özellikle de zaman geçtikçe ve koddaki nesnelerin kesin verileri ve davranışları olmadıkça, yararlı ve tutarlı "hasa" ilişkileri bulmak, yararlı ve tutarlı "hasa" ilişkileri bulmak, gerçek dünya / etki alanı nesneleriyle daha yaygındır. değiştirir. Bu, her zaman toplama sınıflarından miras almayı dışlamanıza neden olmamalıdır; ama müstehcen olabilir.

Her şeyden önce, kullanılabilirlik ile ilgilidir. Kalıtım kullanırsanız, Teamsınıf yalnızca nesne yönetimi için tasarlanmış davranışı (yöntemleri) ortaya koyar. Örneğin, AsReadOnly()ya da CopyTo(obj)yöntemler takım nesnesi için bir anlam ifade etmiyor. AddRange(items)Yöntem yerine muhtemelen daha açıklayıcı bir AddPlayers(players)yöntem istiyorsunuz .

LINQ kullanmak istiyorsanız, ICollection<T>veya gibi genel bir arayüz uygulamak IEnumerable<T>daha mantıklı olacaktır.

Belirtildiği gibi, kompozisyon bu konuda doğru yol. Özel değişken olarak bir oyuncu listesi uygulayın.

Bir futbol takımı futbolcuların bir listesi değildir . Bir futbol takımı oluşmaktadır bir listesinden !

Bu mantıksal olarak yanlış:

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

ve bu doğrudur:

class FootballTeam 
{ 
    public List<FootballPlayer> players
    public string TeamName; 
    public int RunningTotal 
}

Bu koşullara bağlıdır

Takımınızı bir oyuncu listesi olarak gördüğünüzde, bir ayak topu takımının "fikrini" bir yöne yansıtırsınız: "Ekibi" sahada gördüğünüz kişilere indirgersiniz. Bu projeksiyon sadece belirli bir bağlamda doğrudur. Farklı bir bağlamda, bu tamamen yanlış olabilir. Ekibin sponsoru olmak istediğinizi düşünün. Bu yüzden ekibin yöneticileri ile konuşmalısınız. Bu bağlamda ekip, yöneticiler listesine yansıtılır. Ve bu iki liste genellikle çok fazla örtüşmüyor. Diğer bağlamlar, eski oyunculara karşı güncel olanlardır.

Belirsiz anlambilim

Yani bir takımı oyuncularının bir listesi olarak görmenin sorunu, anlamsallığının bağlama bağlı olması ve bağlam değiştiğinde genişletilememesidir. Ek olarak, hangi bağlamı kullandığınızı ifade etmek zordur.

Sınıflar genişletilebilir

Yalnızca bir üyeli (örneğin IList activePlayers) bir sınıf kullandığınızda, bağlamı netleştirmek için üyenin adını (ve ayrıca yorumunu) kullanabilirsiniz. Ek bağlamlar olduğunda, yalnızca ek bir üye eklersiniz.

Sınıflar daha karmaşık

Bazı durumlarda fazladan bir sınıf oluşturmak aşırıya kaçabilir. Her sınıf tanımının sınıf yükleyici aracılığıyla yüklenmesi gerekir ve sanal makine tarafından önbelleğe alınır. Bu, çalışma zamanı performansına ve belleğe mal olur. Çok özel bir bağlamınız olduğunda, bir futbol takımını bir oyuncu listesi olarak kabul etmek uygun olabilir. Ama bu durumda, gerçekten sadece a kullanmalısınız IList , ondan türetilmiş bir sınıf değil.

Sonuç / Düşünceler

Çok özel bir bağlamınız olduğunda, bir takımı oyuncular listesi olarak kabul etmek sorun olmaz. Örneğin, bir yöntemin içinde yazmak tamamen sorun değildir:

IList<Player> footballTeam = ...

F # kullanırken, bir tür kısaltması oluşturmak bile uygun olabilir:

type FootballTeam = IList<Player>

Ancak bağlam daha geniş veya net değilse, bunu yapmamalısınız. Bu, özellikle gelecekte kullanılabilecek bağlamı net olmayan yeni bir sınıf oluşturduğunuzda geçerlidir. Sınıfınıza ek özellikler (takımın adı, koçu vb.) Eklemeye başladığınızda bir uyarı işareti gelir. Bu, sınıfın kullanılacağı bağlamın sabit olmadığı ve gelecekte değişeceğinin açık bir işaretidir. Bu durumda takımı bir oyuncu listesi olarak düşünemezsiniz, ancak (şu anda aktif, yaralanmamış vb.) Oyuncuların listesini takımın bir özelliği olarak modellemelisiniz.

Sorunuzu yeniden yazayım. böylece konuyu farklı bir perspektiften görebilirsiniz.

Bir futbol takımını temsil etmem gerektiğinde, bunun temelde bir isim olduğunu anlıyorum. Gibi: "Kartallar"

string team = new string();

Sonra takımların da oyuncuları olduğunu fark ettim.

Neden dize türünü bir oyuncu listesi içerecek şekilde genişletemiyorum?

Soruna giriş noktanız keyfi. Bir takım yok düşünmek deneyin zorunda değil ne (özelliklerini) olduğunu .

Bunu yaptıktan sonra, özellikleri diğer sınıflarla paylaşıp paylaşmadığını görebilirsiniz. Ve kalıtım hakkında düşünün.

Diğer cevapların hemen hemen bir futbol takımının "a-a" List<FootballPlayer>veya "has-a" olup olmadığınıList<FootballPlayer> .

OP başlıca olarak aşağıdakilerden miras alınmasıyla ilgili kurallar hakkında açıklama ister List<T>:

Bir rehber miras kalmamanız gerektiğini söylüyor List<T>. Neden olmasın?

Çünkü List<T>sanal bir yöntemi yok. Bu, kendi kodunuzda daha az problemdir, çünkü uygulamayı nispeten az acıyla kapatabilirsiniz - ancak genel bir API'da çok daha büyük bir anlaşma olabilir.

Herkese açık bir API nedir ve neden ilgilenmeliyim?

Herkese açık bir API, üçüncü taraf programcılara gösterdiğiniz bir arayüzdür. Çerçeve kodunu düşünün. Ve atıfta bulunulan yönergelerin ".NET Uygulama Tasarımı Yönergeleri" değil, ".NET Framework Tasarım Yönergeleri" olduğunu unutmayın . Bir fark vardır ve - genel olarak konuşursak - genel API tasarımı çok daha katıdır.

Şu anki projemde bu herkese açık API bulunmuyorsa ve bu olasılığa sahip değilse, bu kılavuzu göz ardı edebilir miyim? Listeden miras alırsam ve genel bir API'ya ihtiyacım olduğu ortaya çıkarsa, ne tür zorluklar yaşayacağım?

Neredeyse, evet. Yine de durumunuz için geçerli olup olmadığını görmek için arkasındaki mantığı düşünmek isteyebilirsiniz, ancak genel bir API oluşturmuyorsanız, özellikle sürüm oluşturma gibi API endişeleri hakkında endişelenmenize gerek yoktur (ki bu bir alt kümesi).

Gelecekte herkese açık bir API eklerseniz, API'nızı uygulamanızdan soyutlamanız ( List<T>doğrudan göstermeyerek) veya yönergeleri, gelecekteki olası acıyla ihlal etmeniz gerekir .

Neden önemli? Liste bir listedir. Ne değişebilirdi? Neyi değiştirmek isteyebilirim?

Bağlama bağlıdır, ancak FootballTeamörnek olarak kullandığımızdan FootballPlayer, ekibin maaş sınırının üstesinden gelmesine neden olacaksa bir ekleyemeyeceğinizi hayal edin . Bunu eklemenin olası bir yolu şöyle olacaktır:

 class FootballTeam : List<FootballPlayer> {
     override void Add(FootballPlayer player) {
        if (this.Sum(p => p.Salary) + player.Salary > SALARY_CAP)) {
          throw new InvalidOperationException("Would exceed salary cap!");
        }
     }
 }

Ah ... ama yapamazsınız override Addçünkü virtual(performans nedenleriyle).

Bir uygulamadaysanız (temel olarak sizin ve tüm arayanlarınızın birlikte derlendiği anlamına gelir) artık IList<T>derleme hatalarını kullanmayı ve düzeltmeyi değiştirebilirsiniz :

 class FootballTeam : IList<FootballPlayer> {
     private List<FootballPlayer> Players { get; set; }

     override void Add(FootballPlayer player) {
        if (this.Players.Sum(p => p.Salary) + player.Salary > SALARY_CAP)) {
          throw new InvalidOperationException("Would exceed salary cap!");
        }
     }
     /* boiler plate for rest of IList */
 }

ancak, genel olarak bir üçüncü tarafa maruz kaldıysanız derleme ve / veya çalışma zamanı hatalarına neden olacak bir değişiklik yaptınız.

TL; DR - kurallar herkese açık API'lar içindir. Özel API'lar için istediğinizi yapın.

İnsanların söylemesine izin veriyor mu?

myTeam.subList(3, 5);

hiç mantıklı mı? Değilse bir Liste olmamalıdır.

Bu , "ekip" nesnenizin davranışına bağlıdır . Tıpkı bir koleksiyon gibi davranıyorsa, önce onu düz bir Liste ile temsil etmek uygun olabilir. Ardından, listede yinelenen kodu çoğaltmaya devam ettiğinizi fark etmeye başlayabilirsiniz; bu noktada oyuncu listesini saran bir FootballTeam nesnesi oluşturma seçeneğiniz vardır. FootballTeam sınıfı, oyuncular listesinde yinelenen tüm kodların evi olur.

Kodumu gereksiz yere ayrıntılı yapar. Şimdi sadece my_team.Count yerine my_team.Players.Count çağırmalıyım. Neyse ki, C # ile indekslemeyi şeffaf hale getirmek ve dahili Listenin tüm yöntemlerini iletmek için indeksleyicileri tanımlayabilirim ... Ama bu çok fazla kod! Tüm bu işler için ne alacağım?

Kapsülleme. Müşterilerinizin FootballTeam içinde neler olup bittiğini bilmeleri gerekmez. Tüm müşterilerinizin bildiği gibi, bir veritabanındaki oyuncuların listesine bakarak uygulanabilir. Bilmelerine gerek yok ve bu da tasarımınızı geliştiriyor.

Sadece sade bir anlam ifade etmiyor. Bir futbol takımının oyuncu listesi "yoktur". Oyuncuların listesidir. "John McFootballer SomeTeam oyuncularına katıldı" demiyorsunuz. "John SomeTeam'e katıldı" diyorsunuz. "Bir dizenin karakterlerine" bir harf eklemezsiniz, bir dizeye bir harf eklersiniz. Bir kitaplığın kitaplarına kitap eklemezsiniz, kitaplığa bir kitap eklersiniz.

Kesinlikle :) futbolTeam.Add (john) değil, footballTeam.List.Add (john) diyeceksiniz. Dahili liste görünmez.

Burada çok mükemmel cevaplar var, ancak bahsetmediğim bir şeye değinmek istiyorum: Nesneye yönelik tasarım, nesneleri güçlendirmekle ilgilidir .

Tüm kurallarınızı, ek çalışmalarınızı ve dahili detaylarınızı uygun bir nesnenin içine koymak istiyorsunuz. Bu şekilde, bununla etkileşime giren diğer nesnelerin hepsi için endişelenmesine gerek kalmaz. Aslında, bir adım daha ileri gitmek ve diğer nesnelerin bu iç kısımları atlamasını aktif olarak önlemek istersiniz .

Miras aldığınızda List , diğer tüm nesneler sizi Liste olarak görebilir. Oyuncu ekleme ve çıkarma yöntemlerine doğrudan erişimleri vardır. Ve kontrolünü kaybedeceksin; Örneğin:

Bir oyuncunun emekli olup olmadığını, istifa ettiğini veya işten atıldığını bilerek ayrılmak istediğinizi varsayalım. RemovePlayerUygun bir girdi enum'u alan bir yöntem uygulayabilirsiniz . Ancak, devralan tarafından List, doğrudan erişimi engellemek mümkün olacağını Remove, RemoveAllhatta ve Clear. Sonuç olarak, aslında ettik yetkilerini ellerinden senin FootballTeamsınıf.

Kapsülleme hakkında ek düşünceler ... Aşağıdaki endişeyi dile getirdiniz:

Kodumu gereksiz yere ayrıntılı yapar. Şimdi sadece my_team.Count yerine my_team.Players.Count çağırmalıyım.

Haklısın, bu, tüm müşterilerin seni takımını kullanması için gereksizce ayrıntılı olacaktır. Ancak, bu sorun maruz kaldığınız gerçeğe kıyasla çok küçükList Players ve muhtelif olmanızla böylece sizin izniniz olmadan ekibinizle kemanlanabilirler.

Söylemeye devam et:

Sadece düz bir anlam ifade etmiyor. Bir futbol takımının oyuncu listesi "yoktur". Oyuncuların listesidir. "John McFootballer SomeTeam oyuncularına katıldı" demiyorsunuz. "John SomeTeam'e katıldı" diyorsunuz.

İlk kısımda yanılıyorsunuz: 'liste' kelimesini bırakın ve aslında bir takımın oyuncuları olduğu açıktır.
Ancak, ikincisi ile kafasına çiviyi vurdunuz. İstemcilerin aramasını istemezsiniz ateam.Players.Add(...). Onların aramasını istiyorsun ateam.AddPlayer(...). Ve uygulamanız (muhtemelen diğer şeylerin yanı sıra) Players.Add(...)dahili olarak çağırırdı.

Umarım kapsüllemenin nesnelerinizi güçlendirmek amacıyla ne kadar önemli olduğunu görebilirsiniz. Her sınıfın, diğer nesnelerin karışmasından korkmadan işini iyi yapmasına izin vermek istiyorsunuz.

Bir veri yapısını temsil etmenin doğru C # yolu nedir ...

"Tüm modeller yanlış, ancak bazıları faydalı." - George EP Kutusu

"Doğru bir yol" yoktur, sadece yararlı bir yol vardır.

Sizin ve / kullanıcılarınız için yararlı olanı seçin. Bu kadar. Ekonomik olarak gelişin, fazla mühendislik yapmayın. Ne kadar az kod yazarsanız, o kadar az hata ayıklamanız gerekir. (aşağıdaki sürümleri okuyun).

- Düzenlendi

En iyi cevabım ... duruma göre değişir. Bir Listeden devralma, bu sınıftaki istemcileri, özellikle FootballTeam bir ticari varlık gibi göründüğü için, maruz bırakılmaması gereken yöntemlere maruz bırakacaktır.

- Baskı 2

“Aşırı mühendislik yapma” yorumunda neyi kastettiğimi içtenlikle hatırlamıyorum. KISS zihniyetinin iyi bir rehber olduğuna inanmama rağmen , bir iş sınıfını Listeden devralmanın, soyutlama sızıntısı nedeniyle çözdüğünden daha fazla sorun yaratacağını vurgulamak istiyorum. .

Öte yandan, Listeden miras almanın yararlı olduğu sınırlı sayıda vaka olduğuna inanıyorum. Önceki baskıda yazdığım gibi, duruma göre değişir. Her bir vakanın cevabı bilgi, deneyim ve kişisel tercihlerden büyük ölçüde etkilenir.

@Kai'ye cevap hakkında daha doğru düşünmeme yardımcı olduğu için teşekkürler.

Bu bana hatırlatıyor "karşı mı" karşı "ödünç var". Bazen doğrudan bir süper sınıftan miras almak daha kolaydır ve daha mantıklıdır. Diğer zamanlarda, bağımsız bir sınıf oluşturmak ve üye değişkeni olarak miras alacağınız sınıfı dahil etmek daha mantıklıdır. Sınıfın işlevselliğine yine de erişebilirsiniz, ancak arabirime veya sınıftan devralınmanın getirebileceği diğer kısıtlamalara bağlı değilsiniz.

Hangisini yapıyorsun? Birçok şeyde olduğu gibi ... bağlama bağlıdır. Kullanacağım rehber başka bir sınıftan miras almak için gerçekten bir "bir" ilişki olması gerektiğidir. BMW adında bir sınıf yazıyorsanız, BMW'den bir araba olduğu için Araba'dan miras alabilir. At sınıfı Memeli sınıfından miras alabilir, çünkü bir at gerçek hayatta bir memelidir ve herhangi bir Memeli işlevselliği At ile ilgili olmalıdır. Ama bir takımın bir liste olduğunu söyleyebilir misiniz? Söyleyebileceğim kadarıyla, bir Takım gerçekten "bir" Liste gibi görünmüyor. Yani bu durumda, üye değişkeni olarak bir List olurdu.

Kirli sırrım: İnsanların söylediklerini umursamıyorum ve yapıyorum. .NET Framework, "XxxxCollection" (UIElementCollection ile baş örneğimin üstü) ile yayıldı.

Öyleyse beni durduran şey:

team.Players.ByName("Nicolas")

Daha iyi bulduğumda

team.ByName("Nicolas")

Ayrıca, PlayerCollection'ım herhangi bir kod çoğaltması olmadan "Club" gibi başka bir sınıf tarafından kullanılabilir.

club.Players.ByName("Nicolas")

Dünün en iyi uygulamaları, yarınınki olmayabilir. En iyi uygulamaların arkasında bir neden yoktur, çoğu topluluk arasında sadece geniş bir anlaşmadır. Topluluğa bunu yaptığınızda sizi suçlayıp suçlamayacağını sormak yerine, daha okunabilir ve bakımı daha kolay olan nedir?

team.Players.ByName("Nicolas") 

veya

team.ByName("Nicolas")

Gerçekten mi. Hiç şüphen var mı? Şimdi belki <T> Listesini gerçek kullanım durumunuzda kullanmanızı engelleyen diğer teknik kısıtlamalarla oynamanız gerekebilir. Ancak olmaması gereken bir kısıtlama eklemeyin. Microsoft nedenini belgelemediyse, kesinlikle hiçbir yerden gelen bir "en iyi uygulama" dır.

Yönergelerin söylediği, genel API'nın bir liste, bir küme, bir sözlük, bir ağaç veya başka bir şey kullanıp kullanmadığınıza ilişkin iç tasarım kararını açıklamamasıdır. "Takım" mutlaka bir liste değildir. Bunu bir liste olarak uygulayabilirsiniz, ancak genel API'nizin kullanıcıları sizi sınıfta bilmeleri gereken bir şekilde kullanmalıdır. Bu, genel arayüzü etkilemeden kararınızı değiştirmenize ve farklı bir veri yapısı kullanmanıza olanak tanır.

List<T>"Optimize edilmiş" dedikleri zaman , biraz daha pahalı sanal yöntemler gibi özelliklere sahip olmadığı anlamına gelmek istediklerini düşünüyorum. Dolayısıyla sorun, herkese açık API'nızda ifşa List<T>ettiğinizde , iş kurallarını uygulama veya işlevselliğini daha sonra özelleştirme yeteneğinizi kaybetmenizdir. Ancak bu kalıtsal sınıfı projenizde dahili olarak kullanıyorsanız (binlerce müşterinize / ortaklarınıza / diğer ekiplerinize API olarak maruz kalmanın aksine) zaman kazandırır ve istediğiniz işlevselliktir çiftleme. API'larınızın ömrü boyunca miras almanın avantajı da iyi olabilir.List<T> öngörülebilir gelecekte asla özelleştirilmeyecek birçok aptal sarmalayıcı kodunu ortadan kaldırmanızdır. Ayrıca sınıfınızın açıkça aynı semantiğe sahip olmasını istiyorsanızList<T>

Çoğu insanın FxCop kuralı nedeniyle tonlarca ekstra iş yaptığını sık sık görüyorum ya da birinin blogu bunun "kötü" bir uygulama olduğunu söylüyor. Çoğu zaman, bu, desen palooza garipliğini tasarlamak için kodu açar. Çok sayıda kılavuzda olduğu gibi , istisnaları olabilen kılavuz olarak ele alın .

Bu cevapların çoğunun yaptığı gibi karmaşık bir karşılaştırmam olmasa da, bu durumu ele alma yöntemimi paylaşmak istiyorum. Genişleterek IEnumerable<T>, kendi izin verebilir Teamsınıf alenen tüm yöntem ve özellikleri göstermeden, Linq sorgusu uzantılarını destekleme List<T>.

class Team : IEnumerable<Player>
{
    private readonly List<Player> playerList;

    public Team()
    {
        playerList = new List<Player>();
    }

    public Enumerator GetEnumerator()
    {
        return playerList.GetEnumerator();
    }

    ...
}

class Player
{
    ...
}

Sınıf kullanıcılarınız tüm yöntemlere ve özelliklere ihtiyaç duyuyorsa ** Liste sahipse, sınıfınızı bundan türetmelisiniz. İhtiyaç duymuyorlarsa, listeyi ekleyin ve sınıf kullanıcılarınızın gerçekten ihtiyaç duyduğu yöntemler için sarmalayıcılar oluşturun.

Herkese açık bir API veya birçok kişi tarafından kullanılacak başka bir kod yazarsanız, bu katı bir kuraldır . Küçük bir uygulamanız ve en fazla 2 geliştiriciniz varsa bu kuralı göz ardı edebilirsiniz. Bu size biraz zaman kazandıracaktır.

Küçük uygulamalar için başka, daha az katı bir dil seçmeyi de düşünebilirsiniz. Ruby, JavaScript - daha az kod yazmanıza izin veren her şey.

Eiffel ve tasarımın sözleşmeli mucidi Bertrand Meyer'in bir göz kapağını vurmaktan çok Teammiras alacağını eklemek istedim List<Player>.

Nesneye Yönelik Yazılım İnşaatı kitabında, dikdörtgen pencerelerin alt pencerelere sahip olabileceği bir GUI sisteminin uygulanmasını tartışıyor. O sadece Windowikisinden miras alır Rectangleve Tree<Window>uygulamayı yeniden kullanır.

Ancak, C # Eiffel değil. İkincisi, çoklu kalıtım ve özelliklerin yeniden adlandırılmasını destekler . C # 'ta alt sınıfta, hem arabirimi hem de uygulamayı devralırsınız. Uygulamayı geçersiz kılabilirsiniz, ancak çağrı kuralları doğrudan üst sınıftan kopyalanır. Yeniden adlandırmak böylece Eiffel olarak, ancak, kamu yöntemlerin isimlerini değiştirebilir Addve Removehiç Hireve Fireöğenize Team. Eğer bir örneği Teamtekrar yayınlanırsa List<Player>, arayan onu değiştirecek Addve Removedeğiştirecek, ancak sanal yöntemleriniz Hireve Fireçağrılacaktır.

Bence genellemenize katılmıyorum. Bir takım sadece bir oyuncu topluluğu değildir. Bir takımın adı, amblemi, yönetim / yönetici personelinin toplanması, koçluk ekibinin toplanması, daha sonra oyuncuların toplanması hakkında çok daha fazla bilgisi vardır. Dolayısıyla, FootballTeam sınıfınızda 3 koleksiyon olmalı ve kendisi bir koleksiyon olmamalıdır; gerçek dünyayı düzgün bir şekilde modellemek için.

Specialized StringCollection gibi, iç depoya nesneler eklenmeden veya iç depodan kaldırılmadan önce doğrulama ve kontroller gibi başka özellikler sunan bir PlayerCollection sınıfını düşünebilirsiniz.

Belki de bir PlayerCollection bahisleri fikri tercih ettiğiniz yaklaşıma uyuyor?

public class PlayerCollection : Collection<Player> 
{ 
}

Ve sonra FootballTeam şöyle görünebilir:

public class FootballTeam 
{ 
    public string Name { get; set; }
    public string Location { get; set; }

    public ManagementCollection Management { get; protected set; } = new ManagementCollection();

    public CoachingCollection CoachingCrew { get; protected set; } = new CoachingCollection();

    public PlayerCollection Players { get; protected set; } = new PlayerCollection();
}

Sınıflara Göre Arabirimleri Tercih Etme

Sınıflar sınıflardan türetmekten kaçınmalı ve bunun yerine gerekli asgari arayüzleri uygulamalıdır.

Kalıtım Kapsülleme tatili

Sınıflardan türetme kapsüllemeyi keser :

• koleksiyonunuzun nasıl uygulandığına ilişkin dahili ayrıntıları gösterir
• uygun olmayan bir arabirimi (genel işlevler ve özellikler kümesi) bildirir

Diğer şeylerin yanı sıra bu, kodunuzu yeniden düzenlemeyi zorlaştırır.

Sınıflar Uygulama Detayıdır

Sınıflar, kodunuzun diğer bölümlerinden gizlenmesi gereken bir uygulama ayrıntısıdır. Kısacası a System.List, şimdi ve gelecekte uygun olabilecek veya olmayabilecek soyut bir veri tipinin özel bir uygulamasıdır.

Kavramsal olarak System.Listveri türünün "liste" olarak adlandırılması, biraz kırmızı ringa balığıdır. A System.List<T>, öğelerin eklenmesi, eklenmesi ve çıkarılması için itfa edilmiş O (1) işlemlerini ve öğelerin sayısını almak veya öğeyi dizine göre almak ve ayarlamak için O (1) işlemlerini destekleyen değiştirilebilir bir koleksiyondur.

Arayüz Ne kadar Küçükse Kod Daha Esnek

Bir veri yapısı tasarlanırken arayüz ne kadar basit olursa, kod o kadar esnek olur. Bunun bir gösterimi için LINQ'nun ne kadar güçlü olduğuna bakın.

Arayüzler Nasıl Seçilir

"Liste" diye düşündüğünüzde kendinize, "Beyzbol oyuncularının bir koleksiyonunu temsil etmeliyim" diyerek başlamalısınız. Diyelim ki bunu bir sınıfla modellemeye karar verdiniz. İlk önce yapmanız gereken şey, bu sınıfın ne kadar az arayüz açığa çıkarması gerektiğine karar vermektir.

Bu sürece rehberlik edebilecek bazı sorular:

• Sayıma ihtiyacım var mı? Uygulamayı düşünmüyorsanızIEnumerable<T>
• Bu koleksiyon başlatıldıktan sonra değişecek mi? Değilse düşünün IReadonlyList<T>.
• Öğelere dizine göre erişebilmem önemli mi? DüşünmekICollection<T>
• Koleksiyona ürün eklediğim sipariş önemli mi? Belki bir ISet<T>?
• Eğer gerçekten bu şeyi istiyorsanız o zaman devam edin ve uygulayın IList<T>.

Bu şekilde, kodun diğer kısımlarını beyzbol oyuncuları koleksiyonunuzun uygulama ayrıntılarına bağlamayacaksınız ve arayüze saygı duyduğunuz sürece uygulanma şeklini değiştirmekte özgür olacaksınız.

Bu yaklaşımı kullanarak, kodun okunması, yeniden düzenlenmesi ve tekrar kullanılması kolaylaşır.

Isıtıcıdan Kaçınma Hakkında Notlar

Modern bir IDE'de arayüzlerin uygulanması kolay olmalıdır. Sağ tıklayın ve "Arabirimi Uygula" yı seçin. Ardından, gerekiyorsa tüm uygulamaları bir üye sınıfa iletin.

Bununla birlikte, çok sayıda kazan plakası yazdığınızı fark ederseniz, bunun nedeni, olması gerekenden daha fazla işlev ortaya çıkarmanızdır. Bir sınıftan miras almamanız da aynı nedendir.

Ayrıca uygulamanız için anlamlı olan daha küçük arayüzler ve belki de bu arayüzleri ihtiyacınız olan diğerleriyle eşleştirmek için sadece birkaç yardımcı uzantı işlevi tasarlayabilirsiniz. LinqArray kütüphanesiIArray için kendi arayüzümde kullandığım yaklaşım bu .

Serileştirme ile ilgili sorunlar

Bir yönü eksik. List <> öğesinden devralan sınıflar, XmlSerializer kullanılarak doğru şekilde serileştirilemez . Bu durumda bunun yerine DataContractSerializer kullanılmalıdır veya kendi serileştirme uygulaması gerekir.

public class DemoList : List<Demo>
{
    // using XmlSerializer this properties won't be seralized:
    string AnyPropertyInDerivedFromList { get; set; }     
}

public class Demo
{
    // this properties will be seralized
    string AnyPropetyInDemo { get; set; }  
}

İlave okuma: Bir sınıf <> Listesinden devralındığında, XmlSerializer diğer nitelikleri serileştirmez

Ne zaman kabul edilebilir?

Eric Lippert'i alıntılamak için:

Mekanizmayı uzatan bir mekanizma inşa ederken .List<T>

Örneğin, AddRangeyöntemin yokluğunda bıktınız IList<T>:

public interface IMoreConvenientListInterface<T> : IList<T>
{
    void AddRange(IEnumerable<T> collection);
}

public class MoreConvenientList<T> : List<T>, IMoreConvenientListInterface<T> { }