Neden birinci sınıf koleksiyonları kullanmalıyız?

ThoughtWorks Antolojisi'nde Jeff Bay'in ^(RTF) Object Calisthenics'in kural numarası 4'e göre , " Birinci sınıf koleksiyonları kullan " önerilir .

Kural 4: Birinci sınıf koleksiyonlar

Bu kuralın uygulanması basittir: koleksiyon içeren herhangi bir sınıf başka üye değişken içermemelidir. Her koleksiyon kendi sınıfına sarılır, bu yüzden koleksiyonla ilgili davranışların bir evi var. Filtrelerin bu yeni sınıfın bir parçası haline geldiğini görebilirsiniz. Ayrıca, yeni sınıfınız iki gruba birlikte katılmak veya grubun her öğesine bir kural uygulamak gibi etkinlikleri gerçekleştirebilir.

Bundan anlayabildiğim, toplama işlemini tamamlayan ayrı bir sınıf kullanmamız ve bu koleksiyonun değişiklik verilerini ekleme, silme yöntemlerini kullanmamız gerektiğiydi.

ve buna ihtiyacımız var, böylece hangi veri tipinin koleksiyona girdiğinden ve neyin ortaya çıktığından emin olabiliriz.

Genel koleksiyon kullanmamız durumunda (geçerli olduğu dillerde), bu kurala uymamız gerekir mi?

Önemli bir önemi yoksa lütfen açıklığa kavuşturun.

Tip güvenliği, birinci sınıf koleksiyonları kullanmak için çok küçük bir nedendir. Bağlantınızdan:

Kural 4: Birinci sınıf koleksiyonlar Bu kuralın uygulanması basittir: koleksiyon içeren herhangi bir sınıf başka üye değişken içermemelidir. Her koleksiyon kendi sınıfına sarılır, bu yüzden koleksiyonla ilgili davranışların bir evi var. Filtrelerin bu yeni sınıfın bir parçası haline geldiğini görebilirsiniz. Ayrıca, yeni sınıfınız iki gruba birlikte katılmak veya grubun her öğesine bir kural uygulamak gibi etkinlikleri gerçekleştirebilir.

Buradaki fikir, kendinizi bir koleksiyonda arama, filtreleme, doğrulama veya toplama / kaldırma / yineleme anlambiliminin ötesinde bir şey bulursanız, kod sizden kendi sınıfına koymanızı ister. Yalnızca bir değeri (aramadan sonra) güncellemeniz gerekiyorsa, bu muhtemelen koleksiyon sınıfına girer.

Bunun sebebi oldukça basit, koleksiyonlar geçme eğilimindedir. Yakında 4 farklı sınıfın kendi SearchByID()yöntemi var. Veya Map<Integer, String>bu haritada saklanan içeriğin bağlamı gibi geri dönüş değerleri elde edersiniz . Birinci sınıf koleksiyon, tek bir kaynak dosyaya mal olan basit bir çözümdür. Uygulamada, bunlar bir kez yerleştirildikten sonra (onlar için birim testleri yazmak da çok kolaydır), koleksiyonla ilgili herhangi bir değişikliğin SearchByID, bir int yerine bir GUID alması gerektiği gibi, kullanımı kolaydır .

... koleksiyonu tamamlayan ayrı bir sınıf kullanın ve toplama eklemek, silmek için yöntemlerle bu koleksiyonun verilerini değiştirin

Bu , koleksiyonlarda saklanan nesnelerin türünü garanti etmekten çok daha fazlasını yapar , ancak herhangi bir koleksiyon değişmezini de garanti eder.

Ağaçlar (kırmızı-siyah, AVL vb.) Sıralamaya duyarlıdır ve davranışları uygun olduğunda yeniden dengelenmeye bağlıdır. Karma tablo performansı da uygun yeniden karma işlemine bağlı olacaktır. Her karma haritasına eklediğinizde yük faktörünü kontrol etmeyi hatırlamak ister misiniz?

FWIW, metin bu konuda oldukça açık (ve her şeyi sorunuza göre düzenleyeceğim, bu yüzden başka kimsenin bu RTF'yi indirmesi gerekmiyor):

Her koleksiyon kendi sınıfına sarılır, bu yüzden koleksiyonla ilgili davranışların bir evi var

Türlerle (veya jeneriklerle) ilgisi yoktur, koleksiyonun davranışını verilerle ilişkilendirmekle ilgili her şey.

Jenerikleri destekleyen bir dil kullanıyorsanız , basit yanıt "Hayır" dır . Çünkü dil özelliğinin kendisi bu konuda oldukça iyi bir iş çıkardığı için türü kontrol etmeye gerek yoktur (Java generics deneyimimden).

Ancak, dilden verilen veri yapısını özelleştirmek istediğiniz herhangi bir durumunuz varsa, orijinal veri yapısının etrafında bir sarmalayıcı sınıfı oluşturabilir ve kendi API'larınızı gösterebilir ve yine de orijinal veri yapısının altında yatan uygulamayı kullanabilirsiniz.