Tôi đang triển khai DelegateCommandvà khi tôi sắp triển khai (các) nhà xây dựng, tôi đã đưa ra hai lựa chọn thiết kế sau:

1: Có nhiều nhà xây dựng quá tải

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

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

2: Chỉ có một hàm tạo với tham số tùy chọn

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

Tôi không biết nên sử dụng cái nào vì tôi không biết những lợi thế / bất lợi có thể xảy ra với một trong hai cách được đề xuất. Cả hai có thể được gọi như thế này:

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

Ai đó có thể vui lòng chỉ cho tôi đi đúng hướng và đưa ra phản hồi?

Tôi thích nhiều hàm tạo hơn các giá trị mặc định và cá nhân tôi không thích ví dụ hai hàm tạo của bạn, nó nên được triển khai khác nhau.

Lý do sử dụng nhiều hàm tạo là vì hàm chính có thể kiểm tra xem tất cả các tham số có phải là null không và chúng có hợp lệ hay không trong khi các hàm tạo khác có thể cung cấp các giá trị mặc định cho hàm chính.

Tuy nhiên, trong các ví dụ của bạn, không có sự khác biệt giữa chúng bởi vì ngay cả hàm tạo thứ cấp cũng vượt qua nullnhư một giá trị mặc định và hàm tạo chính cũng phải biết giá trị mặc định. Tôi nghĩ rằng nó không nên.

Điều này có nghĩa là nó sẽ sạch hơn và tách biệt tốt hơn nếu được thực hiện theo cách này:

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(..);
}

lưu ý _ => truechuyển đến hàm tạo chính hiện đang kiểm tra tất cả các tham số nullvà không quan tâm đến bất kỳ giá trị mặc định nào.

Tuy nhiên, điểm quan trọng nhất là khả năng mở rộng. Nhiều nhà xây dựng sẽ an toàn hơn khi có khả năng bạn sẽ mở rộng mã của mình trong tương lai. Nếu bạn thêm nhiều tham số bắt buộc và cuối cùng các tham số tùy chọn phải đến, bạn sẽ phá vỡ tất cả các triển khai hiện tại của mình. Bạn có thể tạo hàm tạo cũ [Obsolete]và thông báo cho người dùng rằng nó sẽ bị xóa cho họ thời gian để chuyển sang triển khai mới mà không phá vỡ mã của họ ngay lập tức.

Mặt khác, việc tạo quá nhiều tham số tùy chọn cũng sẽ gây nhầm lẫn bởi vì nếu một số trong số chúng được yêu cầu trong một kịch bản và tùy chọn trong một kịch bản khác, bạn sẽ cần nghiên cứu tài liệu thay vì chỉ chọn đúng hàm tạo bằng cách chỉ cần nhìn vào tham số của nó.

Xem xét điều duy nhất bạn đang làm trong hàm tạo là phép gán đơn giản, giải pháp hàm tạo duy nhất có thể là lựa chọn tốt hơn trong trường hợp của bạn. Hàm tạo khác không cung cấp chức năng bổ sung và rõ ràng từ thiết kế của hàm tạo với hai tham số mà đối số thứ hai không cần phải cung cấp.

Nhiều hàm tạo có ý nghĩa khi bạn xây dựng một đối tượng từ các loại khác nhau. Trong trường hợp đó, các hàm tạo là sự thay thế của một nhà máy bên ngoài vì chúng xử lý các tham số đầu vào và định dạng chúng thành một biểu diễn thuộc tính bên trong chính xác của lớp đang được xây dựng. Tuy nhiên, điều đó không xảy ra trong trường hợp của bạn do đó tại sao một nhà xây dựng nên là quá đủ.

Tôi nghĩ có hai trường hợp khác nhau mà mỗi cách tiếp cận có thể tỏa sáng.

Đầu tiên, khi chúng ta có các hàm tạo đơn giản (thường là trường hợp, theo kinh nghiệm của tôi), tôi sẽ xem xét các đối số tùy chọn để tỏa sáng.

1. Họ giảm thiểu mã phải được viết (và do đó cũng phải đọc).
2. Bạn có thể đảm bảo rằng tài liệu ở một nơi và không bị lặp lại (điều này rất tệ vì nó mở ra một khu vực phụ có thể bị lỗi thời).
3. Nếu bạn có nhiều đối số tùy chọn, bạn có thể tránh việc có một tập hợp các hàm tạo rất khó hiểu. Heck, thậm chí chỉ với 2 đối số tùy chọn (không liên quan với nhau), nếu bạn muốn các hàm tạo riêng biệt, quá tải, bạn phải có 4 hàm tạo (phiên bản không có bất kỳ, phiên bản nào với mỗi phiên bản và cả hai phiên bản). Điều này rõ ràng là không có quy mô tốt.

Buuuut, có những trường hợp trong đó các đối số tùy chọn trong các hàm tạo chỉ làm cho mọi thứ rõ ràng khó hiểu hơn. Ví dụ rõ ràng là khi các đối số tùy chọn này là độc quyền (nghĩa là không thể được sử dụng cùng nhau). Việc các nhà xây dựng quá tải chỉ cho phép kết hợp các đối số thực sự hợp lệ sẽ đảm bảo biên dịch thời gian thực thi ràng buộc này. Điều đó nói rằng, bạn cũng nên tránh thậm chí gặp phải trường hợp này (ví dụ: với nhiều lớp kế thừa từ một cơ sở, trong đó mỗi lớp thực hiện hành vi độc quyền).