Bir uygulama yapıyorum DelegateCommandve yapıcı (lar) ı uygulamak üzereyken, aşağıdaki iki tasarım seçeneğiyle karşılaştım:

1: Birden fazla aşırı yükleniciye sahip olmak

public DelegateCommand(Action<T> execute) : this(execute, null) { }

public DelegateCommand(Action<T> execute, Func<T, bool> canExecute)
{
    this.execute = execute;
    this.canExecute = canExecute;
}

2: İsteğe bağlı parametreli yalnızca bir kurucuya sahip olmak

public DelegateCommand(Action<T> execute, Func<T, bool> canExecute = null)
{
    this.execute = execute;
    this.canExecute = canExecute;
}

Hangisini kullanacağımı bilmiyorum, çünkü önerilen iki yoldan biriyle ne gibi avantajların / dezavantajların geldiğini bilmiyorum . Her ikisi de böyle çağrılabilir:

var command = new DelegateCommand(this.myExecute);
var command2 = new DelegateCommand(this.myExecute, this.myCanExecute);

Birisi lütfen beni doğru yöne çevirip geribildirim verebilir mi?

Birden fazla kurucuyu varsayılan değerler yerine tercih ediyorum ve şahsen iki kurucu örneğinizden hoşlanmıyorum, farklı şekilde uygulanması gerekiyor.

Birden fazla kurucu kullanmanın nedeni, ana yapının sadece tüm parametrelerin boş olup olmadığını ve geçerli olup olmadıklarını kontrol edebilmesidir, diğer yapıcılar ana yapı için varsayılan değerler sağlayabilir.

Ancak örneklerinizde aralarında fark yoktur, çünkü ikincil kurucu bile nullbir varsayılan değer olarak geçer ve birincil kurucu da varsayılan değeri bilmek zorundadır. Bence olmamalı.

Bu, bu şekilde uygulandığında daha temiz ve daha iyi ayrılacağı anlamına gelir:

public DelegateCommand(Action<T> execute) : this(execute, _ => true) { }

public DelegateCommand(Action<T> execute, Func<T, bool> canExecute)
{
    this.execute = execute ?? throw new ArgumentNullException(..);
    this.canExecute = canExecute ?? throw new ArgumentNullException(..);
}

iletinin, _ => truetüm parametreleri de denetleyen nullve varsayılanları önemsemediğini belirten birincil kurucuya iletildiğini unutmayın.

Ancak en önemli nokta, genişletilebilirliktir. Gelecekte kodunuzu uzatma olasılığınız olduğunda birden fazla yapıcı daha güvenlidir. Daha fazla gerekli parametreler eklerseniz ve isteğe bağlı olanların sona ermesi gerekiyorsa, mevcut tüm uygulamalarınızı kıracaksınız. Eski yapıcıyı oluşturabilir [Obsolete]ve kullanıcılara kodlarını ihlal etmeden yeni uygulamaya geçmeleri için zaman vererek, kaldırılacağını kullanıcılara bildirebilirsiniz.

Öte yandan, isteğe bağlı çok fazla parametre yapmak da kafa karıştırıcı olacaktır çünkü bunların bir senaryoda istenmesi ve diğerinde isteğe bağlı olması durumunda, sadece doğru kurucuya basitçe parametrelerini bakarak bakmak yerine dokümantasyonu incelemeniz gerekir.

Yapıcıda yaptığınız tek şey basit bir ödev olduğu düşünüldüğünde, tek kurucu çözümü sizin durumunuz için daha iyi bir seçim olabilir. Diğer yapıcı ekstra işlevsellik sağlamaz ve yapıcı tasarımından, ikinci argümanın sağlanması gerekmeyen iki parametreli olduğu açıktır.

Birden fazla yapıcı, farklı türlerden bir nesne oluştururken anlamlı olur. Bu durumda, inşaatçılar harici bir fabrikaya ikame olurlar çünkü girdi parametrelerini işlerler ve onları inşa edilen sınıfın doğru bir iç özellik temsiline biçimlendirirler. Ancak bu sizin durumunuzda gerçekleşmez, bu nedenle neden tek bir kurucunun fazlasıyla yeterli olması gerekir.

Her yaklaşımın parlayabileceği iki farklı durum olduğunu düşünüyorum.

İlk olarak, basit kurucularımız olduğunda (ki bu genellikle benim tecrübelerime göre), parlamak için isteğe bağlı argümanları göz önünde bulundururum.

1. Yazılması gereken kodu (ve dolayısıyla okunması gereken) en aza indirir.
2. Dokümantasyonun bir yerde olduğundan ve tekrarlanmadığından emin olabilirsiniz (kötüdür çünkü eski hale gelebilecek fazladan bir alan açar).
3. Çok sayıda isteğe bağlı argüman varsa, kafa karıştırıcı bir dizi oluşturucu kombinasyonundan kaçınabilirsiniz. Heck, sadece isteğe bağlı 2 argümanla (birbiriyle ilgisiz) bile, eğer ayrı, aşırı yüklenen yapıcılar istiyorsanız, 4 yapıcıya sahip olmanız gerekirdi (hiç olmayan versiyon, her bir versiyon, her ikisi de versiyon). Bu belli ki iyi ölçeklenmiyor.

Buuuut, kuruculardaki isteğe bağlı argümanların işleri daha net bir şekilde karıştırdığı durumlar var. Açık bir örnek, bu isteğe bağlı argümanların münhasır olmadığı zamandır (örneğin, birlikte kullanılamaz). Yalnızca gerçekten geçerli argüman kombinasyonlarına izin veren aşırı yüklenicilere sahip olmak, bu kısıtlamanın derlenmesinde derlenmesini sağlayacaktır. Bununla birlikte, bu vaka ile karşılaşmaktan da kaçınmanız gerekir (örneğin, her sınıfın özel davranışı yaptığı bir tabandan miras alan çoklu sınıflarla).