Koleksiyon <T> ve Liste <T> arayüzlerinizde ne kullanmalısınız?

Kod aşağıdaki gibi görünür:

namespace Test
{
    public interface IMyClass
    {
        List<IMyClass> GetList();
    }

    public class MyClass : IMyClass
    {
        public List<IMyClass> GetList()
        {
            return new List<IMyClass>();
        }
    }
}

Kod Analizi Çalıştırdığımda aşağıdaki öneriyi alırım.

Uyarı 3 CA1002: Microsoft.Design: Collection, ReadOnlyCollection veya KeyedCollection kullanmak için 'IMyClass.GetList ()' içindeki 'List' öğesini değiştirin

Bunu nasıl düzeltmeliyim ve burada iyi uygulama nedir?

Sorunun neden olmasa da "neden" bölümünü yanıtlamak için List<T>, nedenleri geleceğe hazırlayan ve API basitliğidir.

Gelecek geçirmezlik

List<T>alt sınıflandırma ile kolayca genişletilebilecek şekilde tasarlanmamıştır; dahili uygulamalar için hızlı olacak şekilde tasarlanmıştır. Üzerindeki yöntemlerin sanal olmadığını fark edeceksiniz ve bu yüzden geçersiz kılınamaz ve Add/ Insert/ Removeişlemlerinde kanca yoktur .

Bu, ileride koleksiyonun davranışını değiştirmeniz gerektiğinde (örneğin, insanların eklemeye çalıştığı boş nesneleri reddetmek veya bu durum gerçekleştiğinde sınıf durumunuzu güncellemek gibi ek işler gerçekleştirmek için), türü değiştirmeniz gerektiği anlamına gelir. toplama sınıfına dönebilirsiniz alt sınıf, ki bu bir kırılma arayüzü değişikliği olacak (tabii ki null izin vermemek gibi şeylerin anlamlarını değiştirmek de bir arayüz değişikliği olabilir, ama iç sınıf durumunuzu güncelleme gibi şeyler olmayacaktır).

Yani ya kolayca gibi sınıflandırma edilebilir bir sınıf döndürerek Collection<T>gibi bir arayüz veya IList<T>, ICollection<T>ya IEnumerable<T>da hala iade edilebilir çünkü tüketicilerin kodunu bozmadan, kendi ihtiyaçlarını karşılamak için farklı bir koleksiyon türü olmak için iç uygulanmasını değiştirebilir bekliyorlar.

API Basitliği

List<T>gibi yararlı bir operasyon çok içerir BinarySearch, Sortve böyle devam eder. Bununla birlikte, bu ortaya koyduğunuz bir koleksiyonsa, tüketicilerin değil, listenin anlambilimini kontrol etmeniz muhtemeldir. Sınıfınız dahili olarak bu işlemlere ihtiyaç duysa da, sınıfınızın tüketicilerinin onları aramak istemesi (hatta hatta yapması) pek olası değildir.

Bu nedenle, daha basit bir toplama sınıfı veya arayüzü sunarak API'nizin kullanıcılarının gördüğü üye sayısını azaltır ve kullanımlarını kolaylaştırırsınız.

Şahsen bunu somut bir koleksiyondan ziyade bir arayüz iade ettiğini beyan ederim. Listeye gerçekten erişmek istiyorsanız, tuşunu kullanın IList<T>. Aksi takdirde, düşünün ICollection<T>ve IEnumerable<T>.

Kimsenin "neden" kısmına henüz cevap vermediğini sanmıyorum ... işte gidiyor. A Collection<T>yerine "neden" siz "kullanmanızın List<T>nedeni, a'yı ortaya çıkarırsanız List<T>, nesnenize erişen herkesin listedeki öğeleri değiştirebilmesidir. Oysa Collection<T>kendi "Ekle", "Kaldır" vb. Yöntemlerinizi yaptığınızı belirtmesi gerekir.

Muhtemelen bunun için endişelenmenize gerek yok, çünkü muhtemelen arayüzü sadece kendiniz (veya belki de birkaç meslektaşınız için) kodluyorsunuz. İşte mantıklı olabilecek başka bir örnek.

Herkese açık bir diziniz varsa, ör:

public int[] MyIntegers { get; }

Hiç kimsenin değerlerle uğraşamayacağı bir "get" erişimcisi olduğu için düşünürsünüz, ama bu doğru değil. Herkes içindeki değerleri şu şekilde değiştirebilir:

someObject.MyIngegers[3] = 12345;

Şahsen, List<T>çoğu durumda kullanırım. Ancak rastgele geliştiricilere vereceğiniz bir sınıf kütüphanesi tasarlıyorsanız ve nesnelerin durumuna güvenmeniz gerekiyorsa ... o zaman kendi Koleksiyonunuzu yapmak ve oradan kilitlemek istersiniz: )

Bu, çoğunlukla List nesnesini doğrudan manipüle edilmek yerine kendi uygulamalarınızı soyutlamakla ilgilidir.

Diğer nesnelerin (veya kişilerin) doğrudan nesnelerinizin durumunu değiştirmesine izin vermek iyi bir uygulama değildir. Mülkiyet alıcılarını / düzenleyicilerini düşünün.

Koleksiyon -> Normal koleksiyon için
ReadOnlyCollection -> Değiştirilmemesi gereken koleksiyonlar için
KeyedCollection -> Bunun yerine sözlük istediğinizde.

Nasıl düzeltileceği, sınıfınızın ne yapmasını istediğinize ve GetList () yönteminin amacına bağlıdır. Detaylandırabilir misin?

Bu tür bir durumda genellikle gerekli olan en az miktarda uygulamayı ortaya çıkarmaya çalışırım. Tüketicilerin aslında bir liste kullandığınızı bilmeleri gerekmiyorsa, bir liste döndürmeniz gerekmez. Microsoft'un bir Koleksiyon önerdiği gibi geri dönerek, sınıfınızın tüketicilerinden bir liste kullandığınız gerçeğini gizler ve bunları dahili bir değişikliğe karşı izole edersiniz.

Eklenmesi gereken bir şey, bu sorulduğundan beri uzun zaman geçti.

Liste türünüz List<T>yerine türetildiğinde, Collection<T>uygulanmış korumalı sanal yöntemleri Collection<T>uygulayamazsınız. Bunun anlamı türetilmiş türün listede herhangi bir değişiklik yapılması durumunda yanıt veremeyeceğidir. Bunun nedeni List<T>, öğe eklediğinizde veya kaldırdığınızda farkında olduğunuzu varsayar. Bildirimlere yanıt verebilmek bir ek yüktür ve bu nedenle List<T>önermez.

Harici kodun koleksiyonunuza erişimi olduğu durumlarda, bir öğenin ne zaman ekleneceğini veya kaldırılacağını kontrol edemeyebilirsiniz. Bu nedenle Collection<T>, listenizin ne zaman değiştirildiğini bilmek için bir yol sağlar.

Gibi bir şey döndürürken herhangi bir sorun görmüyorum

this.InternalData.Filter(crteria).ToList();

Dahili verilerin bağlantısı kesilmiş bir kopyasını veya bir veri sorgusunun ayrılmış sonucunu döndürdüysem - List<TItem>Uygulama ayrıntılarını göstermeden güvenli bir şekilde geri dönebilirim ve iade edilen verileri uygun bir şekilde kullanmaya izin verebilirim.

Ancak bu, ne tür bir tüketici beklediğime bağlıdır - bu veri ızgarası gibi bir şeyse, çoğu durumda yine de IEnumerable<TItem> öğelerin kopyalanan listesi olacak geri dönmeyi tercih ederim :)

Koleksiyon sınıfı, uygulama ayrıntılarını ve diğer özelliklerini gizlemek için diğer koleksiyonların etrafındaki bir sarmalayıcı sınıftır. Bunun, nesne yönelimli dillerde kodlama desenini gizleyen özellik ile ilgisi olduğunu düşünüyorum.

Bu konuda endişelenmemelisiniz, ancak gerçekten kod analiz aracını memnun etmek istiyorsanız, sadece aşağıdakileri yapın:

//using System.Collections.ObjectModel;

Collection<MyClass> myCollection = new Collection<MyClass>(myList);