Soyut veya sanal yöntemler kullanmalı mıyım?

Temel sınıfın saf bir arabirim sınıfı olmasını ve soyut veya sanal yöntem sınıfı tanımını kullanarak daha iyi bir yaklaşım olan aşağıdaki 2 örneği kullanmanın istenmediğini varsayarsak?

• "Soyut" versiyonun avantajı, muhtemelen daha temiz görünmesi ve türetilmiş sınıfı umut verici bir uygulama yapmaya zorlamasıdır.

• "Sanal" sürümün avantajı, diğer modüller tarafından kolayca çekilebilmesi ve soyut sürümün gerektirdiği gibi bir grup temel çerçeve eklemeden test için kullanılabilmesidir.

Özet Versiyon:

public abstract class AbstractVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Sanal Sürüm:

public class VirtualVersion
{
    public virtual ReturnType Method1()
    {
        return ReturnType.NotImplemented;
    }

    public virtual ReturnType Method2()
    {
        return ReturnType.NotImplemented;
    }
             .
             .
    public virtual ReturnType MethodN()
    {
        return ReturnType.NotImplemented;
    }

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Oyumu, eğer eşyalarını tüketiyor olsaydım, soyut yöntemler için olurdu. Bu "erken başarısız" ile birlikte gider. Tüm yöntemleri eklemek için beyan zamanında bir acı olabilir (herhangi bir iyi refactoring aracı bunu hızlı bir şekilde yapacaktır), ancak en azından sorunun hemen ne olduğunu biliyorum ve düzeltin. Neden aniden uygulanmayan bir istisna aldığımızı görmek için 6 ay ve 12 kişinin değişiklik değerinde hata ayıklamak yerine.

Sanal sürüm hataya açık ve anlamsal olarak yanlıştır.

Özet "bu yöntem burada uygulanmıyor. Bu sınıfın çalışması için onu uygulamalısın" diyor.

Virtual, "Varsayılan bir uygulamam var ancak ihtiyacınız olursa beni değiştirebilirsiniz" diyor

Nihai hedefiniz test edilebilirlikse, arayüzler normalde en iyi seçenektir. (bu sınıf bu sınıftan ziyade x yapar). Güzel çalışması için sınıflarınızı daha küçük bileşenlere ayırmanız gerekebilir.

Bu, sınıfınızın kullanımına bağlıdır.

Yöntemlerin makul “boş” bir uygulaması varsa, birçok yönteminiz vardır ve çoğu zaman bunlardan sadece birkaçını geçersiz kılarsınız, o zaman virtualyöntemleri kullanmak mantıklıdır. Örneğin ExpressionVisitorbu şekilde uygulanır.

Aksi takdirde, abstractyöntemleri kullanmanız gerektiğini düşünüyorum .

İdeal olarak, uygulanmayan yöntemlere sahip olmamalısınız, ancak bazı durumlarda bu en iyi yaklaşımdır. Ancak bunu yapmaya karar verirseniz, bu tür yöntemler NotImplementedExceptionözel bir değer döndürmemeli, atmalıdır .

Temel sınıfınızın uyguladığı ayrı bir arabirime sahip olmayı yeniden düşünmenizi ve ardından soyut yaklaşımı izlemenizi öneririm.

Görüntüleme kodu şöyle:

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public abstract class AbstractVersion : IVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Bunu yapmak şu sorunları çözer:

1. AbstractVersion'dan türetilen nesneleri kullanan tüm kodlara sahip olmak artık IVersion arayüzünü almak için uygulanabiliyor.

2. Ürününüzün 2. sürümü, mevcut müşteri kodunuzu kırmadan ek işlevsellik sağlamak için IVersion2 arabirimini uygulayabilir.

Örneğin.

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public interface IVersion2
{
    ReturnType Method2_1();
}

public abstract class AbstractVersion : IVersion, IVersion2
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();
    public abstract ReturnType Method2_1();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Ayrıca, bu sınıfın etkili birim testini önleyen sabit kodlu bağımlılıklar içermesini önlemek için bağımlılık ters çevirme hakkında da okumaya değer.

Bağımlılık enjeksiyonu arayüzlere dayanır. Kısa bir örnek. Class Student, "IReporting" arabirimini (ReportAction yöntemiyle) uygulayan bir parametre gerektiren CreateStudent adlı bir işleve sahiptir. Bir öğrenci oluşturduktan sonra, beton sınıfı parametresinde ReportAction'ı çağırır. Sistem bir öğrenci oluşturduktan sonra e-posta gönderecek şekilde ayarlanmışsa, ReportAction uygulamasında bir e-posta gönderen somut bir sınıfta göndeririz veya ReportAction uygulamasında bir yazıcıya çıktı gönderen başka bir somut sınıfta gönderebiliriz. Kod yeniden kullanım için harika.