C # 'daki üyeleri gizlemek için açık arabirim uygulaması kullanma izni var mı?

C # arayüzleri ve açık arabirim uygulaması ile nasıl çalışacağını anlıyorum, ancak sık kullanılmayacak belirli üyeleri gizlemek için kötü bir form olarak kabul edilip edilmediğini merak ediyordum. Örneğin:

public interface IMyInterface
{
    int SomeValue { get; set; }
    int AnotherValue { get; set; }
    bool SomeFlag { get; set; }

    event EventHandler SomeValueChanged;
    event EventHandler AnotherValueChanged;
    event EventHandler SomeFlagChanged;
}

Olayların yararlı olsa da çok nadiren kullanılacağını önceden biliyorum. Bu nedenle, IntelliSense karmaşasından kaçınmak için onları açık bir uygulama yoluyla bir uygulayıcı sınıftan gizlemenin mantıklı olacağını düşündüm.

Evet, genellikle kötü bir formdur.

Bu nedenle, IntelliSense karmaşasından kaçınmak için onları açık bir uygulama yoluyla bir uygulayıcı sınıftan gizlemenin mantıklı olacağını düşündüm.

IntelliSense'iniz çok dağınıksa, sınıfınız çok büyük. Sınıfınız çok büyükse, çok fazla şey yapıyor ve / veya kötü tasarlanmış.

Sorununuzu düzeltin, belirtinizi değil.

Özelliği, amaçlandığı gibi kullanın. Ad alanı karmaşasını azaltmak bunlardan biri değil.

Meşru nedenler "gizlemek" veya organizasyonla ilgili değildir, belirsizliği çözmek ve uzmanlaşmak içindir. "Foo" tanımlayan iki arabirim uygularsanız, Foo'nun semantiği farklı olabilir. Açık arabirimler dışında bunu çözmek için gerçekten daha iyi bir yol değil. Alternatif, çakışan arayüzlerin uygulanmasına izin vermemek veya arayüzlerin anlambilimi ilişkilendiremeyeceğini bildirmektir (bu zaten kavramsal bir şeydir). Her ikisi de zayıf alternatiflerdir. Bazen pratiklik zarafeti yitirir.

Bazı yazarlar / uzmanlar bunun bir özellik küfürü olduğunu düşünmektedir (yöntemler türün nesne modelinin bir parçası değildir). Ancak tüm özellikler gibi, bir yerlerde de birinin buna ihtiyacı vardır.

Yine, olur değil gizleme veya kuruluş için kullanabilirsiniz. Üyeleri zekâdan gizlemenin yolları vardır.

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

Dağınık kodun bir işareti olabilirim, ama bazen gerçek dünya dağınık. .NET çerçevesinden bir örnek, değiştirici ayarlayıcı [], Ekle ve Ayarla'yı gizleyen ReadOnlyColection'dur .

IE ReadOnlyCollection IList <T> uygular. Birkaç yıl önce bunu düşündüğümde SO'ya olan sorumu da görün .

Üye bağlamda anlamsız olduğunda bunu yapmak iyi bir formdur. Örneğin, IList<T>dahili bir nesneye yetki vererek uyguladığınız salt okunur bir koleksiyon oluşturursanız, şöyle bir _wrappedşeye sahip olabilirsiniz:

public T this[int index]
{
  get
  {
     return _wrapped[index];
  }
}
T IList<T>.this[int index]
{
  get
  {
    return this[index];
  }
  set
  {
    throw new NotSupportedException("Collection is read-only.");
  }
}
public int Count
{
  get { return _wrapped.Count; }
}
bool ICollection<T>.IsReadOnly
{
  get
  {
    return true;
  }
}

Burada dört farklı vakamız var.

public T this[int index]arayüzden ziyade sınıfımız tarafından tanımlanır ve bu nedenle elbette açık bir uygulama değildir, ancak T this[int index]arayüzde tanımlanan okuma-yazma işlemine benzediğini, ancak salt okunur olduğunu unutmayın .

T IList<T>.this[int index]açıktır, çünkü bir kısmı (alıcı) yukarıdaki mülkle mükemmel bir şekilde eşleşir ve diğer kısmı her zaman bir istisna atar. Arayüz yoluyla bu sınıfın bir örneğine erişen biri için hayati olmakla birlikte, sınıf türünün bir değişkeni aracılığıyla kullanan birisinin anlamı yoktur.

Benzer şekilde bool ICollection<T>.IsReadOnly, her zaman doğru döneceğinden, sınıfın türüne karşı yazılan kodu tamamen anlamsızdır, ancak arayüzün türü aracılığıyla bunu kullanması için hayati önem taşıyabilir ve bu nedenle açıkça uygularız.

Buna karşılık, public int Countkendi türüyle bir örneği kullanan biri için potansiyel olarak yararlı olabileceğinden açıkça uygulanmaz.

Ancak "çok nadiren kullanılan" durumunuzla, açık bir uygulama kullanmamaya çok güçlü bir şekilde eğilirim.

Sınıf türünün bir değişkeni yoluyla yöntemi çağıran açık bir uygulama kullanmanızı öneririm durumlarda ya bir hata (dizinlenmiş ayarlayıcıyı kullanmaya çalışırken) ya da anlamsız (her zaman aynı olacak bir değeri denetleme) kullanıcıyı buggy veya en uygun olmayan koddan koruyorsunuz. Bu, nadiren kullanıldığını düşündüğünüz koddan önemli ölçüde farklıdır . Bunun için EditorBrowsableüyeyi zekâdan gizlemek için bu özelliği kullanmayı düşünebilirim ; insanların beyninin zaten ilgilerini çekmeyen şeyleri filtrelemek için kendi yazılımları var.