Ortak yöntemden hashtable döndürmede yanlış olan nedir ve ne zaman yapılması mantıklıdır?

Bir sınıf oluşturmak ve bunun nesnesini döndürmek yerine birden fazla öğe döndürmek istediğinizde, genel bir yöntemden bir hashtable döndürmede tasarım sorunları nelerdir?

Sorunları varsa, hangi koşullar altında bunu yapmak mantıklıdır?

Bu sorunun cevabı, dilin dinamik olup olmamasına bağlı olarak nasıl değişir?

Düzenleme: Bu, anahtarların sabit olacağını ve verilerin değil kodun bir parçası olduğunu açıklığa kavuşturmak içindir. Tipik olarak sınıf oluşturduğumuz bir şey. Soru şu ki, bir sınıf oluşturmak gerçekten doğru bir seçim gibi görünüyorsa bunun yerine hashtable kullanmak yanlış olur.

Dönüş türü olarak, rasgele sayıda değeri ad / değer çifti olarak tutan bir karma değerinden daha iyi tanımlanmış bir sınıf kullanın.

1. İlk ve en önemli nokta - Sürdürülebilirlik. Koda bakarak, yeni bir programcı asla yöntemin döndürdüğü değerlerin ne olduğunu söyleyemez. Yeni bir kişi, koda bakarak bunu anlamazsa, bir kullanıcı bu verilere daha fazla anahtar / değer ekleyecek veya uygulamayı geliştirecek olduğunda kod yararlı olmayacak ve hatalara eğilimli olmayacaktır.

2. Yöntemler, arayan ile hizmet arasındaki sözleşmelerdir. Bir yöntemdeki en önemli şey girdi ve çıktılarıdır. Bu giriş ve çıkış kolaylıkla okunabilir ve anlaşılabilir olmalı ve kendi kendini belgelemelidir. Bir Person sınıfını, adı, soyadı, yaşı olan bir dönüş değeri olarak kullanırsanız, bu kendi kendini belgelendirir. Bunun için bir Javadoc oluşturursanız, kullanıcı bunu daha iyi anlamak için sınıflar arasında gezinebilir. Bir hashtable kullanıyorsanız, yorumlarda kimsenin okumayacağı ya da bir şeyler değiştiğinde güncellenmeyeceğini açıklamanız gerekir.

3. HashMap<String,String>Dönüş ifadesine bir sayı (yaş diyelim) eklemek istiyorsanız, gibi jenerikleri kullanamazsınız . Jenerik kullanmıyorsanız, nesne arasında gerçek türe geri ve ileri atmanız gerekir. Dinamik yazmayı kullanıyorsanız bunu kaydedebilirsiniz.

4. Ayrıca derleme zamanında sorunları yakalamak daha fazla çalışma zamanı hatası şansı vardır. örneğin birisi hashmap'den bir girişi silerse ve eski arayanlardan biri girişi beklerse, istemci çalışma sırasında başarısız olur. Derleme zamanında bu sorunu yakalamak her zaman daha iyidir.

5. Eğer hashmap'ı dönüş türü olarak kullanmak istiyorsanız değişmez bir türü geri döndürmek zor olacaktır. Ancak kendi türünüzü tanımlayan bir kullanıcı kullanıyorsanız bunu kontrol edebilirsiniz.

Başlangıçta birkaç sınıf oluşturmaktan kaçınabileceğiniz için dönüş türü olarak bir hashmap kullanmak cazip gelecektir, ancak gelecekte kodu korumak bir kabus olacaktır. Nesne yönelimli gidin !!!!

Sorunlardan biri, birçok durumda, karma tablosunun anahtarının bir dize olmasıdır. Bu nedenle yöntemin tüketicileri, verileri ayıklamak için hangi anahtarların kullanılacağını bilmek zorundaydı. Bu, verilere erişilirken yanlış yazılmalardan kaynaklanan hatalar için potansiyel oluşturur.

Diğer bir dezavantaj, yeniden kaplanabilirliktir. Daha sonra bir üyenin adını değiştirmeye karar verirseniz, değiştirmeniz gereken bir sürü sihirli dizeye sahip olursunuz. Çoğu iyi IDE tarafından sağlanan yeniden düzenleme araçlarını kullanarak bir sınıf üyesini yeniden adlandırmak çok daha kolaydır. Karma tabloyla, sorunlu olabilecek tüm kaynak dosyalar üzerinde bir bul / değiştir işlemi yapmanız gerekecektir.

Son olarak, hem erişim hem de ad açısından üye erişiminin derleme zamanı denetimini kaybedersiniz. Karma tablonuz sadece bir tür obejct içeriyorsa, ikincisi böyle bir sorun değildir, ancak çok sayıda (aynı hiyerarşi zincirinde bile) içeriyorsa, gerçekten dilinizin tür sistemini kullanmak ve orada derleme zamanı almak istersiniz. Çoğu IDE'de bir çeşit intellisense / autocomplete özelliklerine sahip olacaksınız - bunlar tür sistemine bakarak çalışır, ancak hash tablo anahtarlarında size yardımcı olmazlar.

Bir karma tablosunun (veya anahtar değer çiftlerinin böyle bir koleksiyonunun) döndürülmesinin uygun olacağı zamanlarda olduğu gibi , derleme zamanında hem değerler hem de anahtarlar bilinmediğinde bunu kullanırsınız . Örneğin, bir sorgu dizesini ayrıştıran ve anahtarları ve karşılık gelen değerleri döndüren bir yönteminiz varsa, bir karma tablosu iyi bir seçim olacaktır. Bu durumda, bir tür değişmez veya salt okunur hash tablosu döndürmeyi de düşünmek istersiniz.

Düzenle - Bu cevapta dile getirilen noktaların çoğu, dinamik dillerden bahsederken geçerli değildir :)

Buna karşı en önemli argüman, tüketiciye çok fazla bilgi vermenizdir. Tüketici kodunun sadece bir çeşit anahtar / değer koleksiyonu (sözlük) olduğunu bilmesi gerekir; bir hashmap, bir ilişkilendirme listesi, bir üçlü veya herhangi bir şey olarak uygulanıp uygulanmadığı nispeten ilgi çekicidir. Bu nedenle uygun yol, IDictionarygerçek türe göre uygun bir arayüzle ( veya seçtiğiniz dilin kullandığı her neyse) geri dönmek olacaktır .

Tüm bunlar, verilerinizi temsil etmek için bir sözlüğe ihtiyacınız olduğunu varsayarsak, verileriniz, anahtarların veri kümesi arasında benzersiz olduğu ve derleme zamanında düzeltilemediği anahtar / değer çiftlerinden oluşur. Önceden bilinen anahtarlarınız varsa, verileriniz için uygun bir tür (veya gerektiğinde birkaç tane) oluşturmalısınız. Anahtarların kendilerini verilerin bir parçası mı, yoksa kodun bir parçası olarak mı görüyorsunuz.

DÜZENLE :

Açıklığa kavuşturmak için, burada anahtar terimi veri yapısının en genel türü anlamında sözlük terimini kullanıyorum ; Python dictveya .NET gibi herhangi bir dile özgü uygulama demek istemiyorum Dictionary.

Kendime soracağım bir soru, "bu sözlükte anahtarlar değişiyor mu?" Bunlar sabitse, bir nesneyi veya diğer uygun veri yapısını döndürmelisiniz. Dinamik olmaları durumunda, bir tür sözlük stili yapısı döndürmek isteyebilirsiniz. Son olarak, sabit olacak bazı anahtarlar ve bazı bilinmeyen dinamik anahtarlar kümesi varsa, bazı sabit değerler ve taşma için bir tür sözlük içeren karma bir veri yapısı döndürmek isteyebilirsiniz.