Asla kamu üyelerini sanal / soyut yapmayın - gerçekten?

2000'li yıllarda bir meslektaşım bana kamu yöntemlerini sanal veya soyut yapmanın bir anti-desen olduğunu söyledi.

Örneğin, iyi tasarlanmamış böyle bir sınıfı düşündü:

public abstract class PublicAbstractOrVirtual
{
  public abstract void Method1(string argument);

  public virtual void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    // default implementation
  }
}

Dedi ki;

• uygulanan Method1ve geçersiz kılan türetilmiş bir sınıfın geliştiricisi Method2, argüman doğrulamasını tekrarlamak zorundadır.
• temel sınıf geliştiricisinin Method1veya Method2daha sonra özelleştirilebilir kısmına bir şey eklemeye karar vermesi durumunda bunu yapamaz.

Bunun yerine meslektaşım bu yaklaşımı önerdi:

public abstract class ProtectedAbstractOrVirtual
{
  public void Method1(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method1Core(argument);
  }

  public void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method2Core(argument);
  }

  protected abstract void Method1Core(string argument);

  protected virtual void Method2Core(string argument)
  {
    // default implementation
  }
}

Bana kamusal yöntemleri (veya mülkleri) sanal veya soyut yapmanın alanları kamusal yapmak kadar kötü olduğunu söyledi. Alanları mülklere sararak, gerekirse daha sonra bu alanlara herhangi bir erişimi engelleyebilir. Aynı durum genel sanal / soyut üyeler için de geçerlidir: onları ProtectedAbstractOrVirtualsınıfta gösterildiği gibi sarmalamak temel sınıf geliştiricisinin sanal / soyut yöntemlere giden çağrıları durdurmasına izin verir.

Ama bunu bir tasarım kılavuzu olarak görmüyorum. Microsoft bile bunu izlemez: Bunu Streamdoğrulamak için sınıfa bir göz atın .

Bu rehber hakkında ne düşünüyorsun? Herhangi bir anlam ifade ediyor mu veya API'yı aşırı karmaşıklaştırdığını mı düşünüyorsunuz?

söz

Yöntem1'i uygulayan ve Yöntem2'nin geçersiz kılma işlemini yinelemesi gereken türetilmiş bir sınıfın geliştiricisi nedeniyle genel yöntemleri sanal veya soyut hale getirmenin bir anti-desen olduğunu

neden ve etkiyi karıştırıyor. Her geçersiz kılınabilen yöntemin özelleştirilemez bir bağımsız değişken doğrulaması gerektirdiği varsayımını yapar. Ama bu tam tersi:

Eğer (- Daha genel - veya özelleştirilebilir ve olmayan özelleştirilebilir parçası) bir bütün sınıfın sözcükler bazı sabit argüman doğrulamaları sağlayan bir şekilde bir yöntem tasarlamak istiyor sonra o giriş noktası olmayan sanal hale getirmek için mantıklı bunun yerine dahili olarak adlandırılan özelleştirilebilir bölüm için sanal veya soyut bir yöntem sağlayın.

Ancak, kişiselleştirilemeyen sabit bir parça olmadığından, genel bir sanal yönteme sahip olmanın mükemmel mantıklı olduğu birçok örnek vardır: ToStringveya gibi standart yöntemlere bakın Equalsveya GetHashCode- objectsınıfın halka açık olmaması için tasarımını geliştirir mi ve aynı anda sanal mı? Ben öyle düşünmüyorum.

Veya kendi kodunuz açısından: temel sınıftaki kod nihayet ve bilerek böyle göründüğünde

 public void Method1(string argument)
 {
    // nothing to validate here, all strings including null allowed
    this.Method1Core(argument);
 }

görünürde hiçbir neden olmaksızın bu ayrımı sadece bir şey arasında yapmak Method1ve Method1Corekarmaşıklaştırmak.

Bunu meslektaşınızın önerdiği şekilde yapmak, temel sınıfın uygulayıcısı için daha fazla esneklik sağlar. Ancak bununla birlikte, varsayılan olarak varsayılan faydalarla doğrulanmayan daha karmaşıktır.

Temel sınıf uygulayıcısı için artan esnekliğin , öncelikli taraf için daha az esneklik pahasına olduğunu unutmayın . Özellikle umursamayacakları bazı dayatılan davranışlar kazanırlar. Onlara göre işler daha da katılaştı. Bu haklı ve yararlı olabilir, ancak bunların hepsi senaryoya bağlıdır.

Bunu uygulamak için adlandırma kuralı (bildiğim), genel arabirimin iyi adını ayırmak ve dahili yöntemin adını "Do" ile önek olarak kullanmaktır.

Yararlı bir durum, gerçekleştirilen eylemin bazı kurulumlara ve bazı kapanmalara ihtiyaç duymasıdır. Bir akışı açma ve overrider yapıldıktan sonra onu kapatma gibi. Genel olarak, aynı tür başlatma ve sonlandırma. Kullanmak için geçerli bir örüntüdür, ancak tüm soyut ve sanal senaryolarda kullanımını zorunlu kılmak anlamsız olacaktır.

C ++ 'da buna sanal olmayan arayüz kalıbı (NVI) denir . (Bir zamanlar, Şablon Yöntemi olarak adlandırıldı. Bu kafa karıştırıcıydı, ancak bazı eski makalelerde bu terminoloji var.) NVI, en az birkaç kez yazmış olan Herb Sutter tarafından destekleniyor. Bence en erken biri burada .

Doğru hatırlamak, öncül bir türetilmiş sınıf değişmez gerektiğidir neyi taban sınıfı yapar ama nasıl bunu yapar.

Örneğin, bir Şeklin, şeklin yerini değiştirmek için bir Move yöntemi olabilir. Somut uygulamalar (örneğin, Kare ve Çemberler gibi) Taşı'yı doğrudan geçersiz kılmamalıdır; çünkü Şekil, Hareketin ne anlama geldiğini tanımlar (kavramsal düzeyde). Bir Kare, konumun dahili olarak nasıl temsil edildiği açısından bir Circle'dan farklı uygulama ayrıntılarına sahip olabilir, bu nedenle Taşıma işlevselliğini sağlamak için bazı yöntemleri geçersiz kılmaları gerekir.

Basit örneklerde, bu genellikle tüm işleri özel bir sanal ReallyDoTheMove'a devreten herkese açık bir hamle kadar kaybolur, bu yüzden fayda için çok fazla yük gibi görünür.

Ancak bu bire bir yazışma şart değildir. Örneğin, Shape'nin genel API'sına bir Animate yöntemi ekleyebilir ve bunu bir döngüde ReallyDoTheMove öğesini çağırarak uygulayabilirsiniz. Her ikisi de tek bir soyut soyut yönteme dayanan iki genel sanal olmayan yöntem API'siyle sonuçlanırsınız. Çevrelerinizin ve Karelerinizin fazladan bir iş yapmasına veya geçersiz kılma Animate'e gerek yoktur .

Temel sınıf, tüketiciler tarafından kullanılan genel arabirimi tanımlar ve bu genel yöntemleri uygulamak için ihtiyaç duyduğu ilkel işlemler arabirimini tanımlar. Elde edilen türler, bu ilkel işlemlerin uygulamalarını sağlamaktan sorumludur.

Sınıf tasarımının bu yönünü değiştirecek C # ve C ++ arasındaki farkların farkında değilim.