Phương thức tạo tĩnh - ưu và nhược điểm so với các hàm tạo

Những ưu và nhược điểm của việc có các phương thức tạo đối tượng tĩnh so với các hàm tạo là gì?

class Foo {
  private Foo(object arg) { }

  public static Foo Create(object arg) {
    if (!ValidateParam(arg)) { return null; }
    return new Foo(arg);
  }
}

Vài điều mà tôi có thể nghĩ đến:

Ưu điểm:

• Trả về null thay vì ném một ngoại lệ (đặt tên cho nó TryCreate). Điều này có thể làm cho mã ngắn gọn hơn và sạch hơn về phía khách hàng. Khách hàng hiếm khi mong đợi một nhà xây dựng thất bại.
• Tạo các loại đối tượng khác nhau với ngữ nghĩa rõ ràng, ví dụ CreatFromName(String name)vàCreateFromCsvLine(String csvLine)
• Có thể trả về một đối tượng được lưu trữ nếu cần thiết hoặc thực hiện dẫn xuất.

Nhược điểm:

• Ít khám phá hơn, khó đọc mã hơn.
• Một số mẫu, như tuần tự hóa hoặc phản chiếu là khó khăn hơn (ví dụ Activator<Foo>.CreateInstance())

Hạn chế lớn nhất với ' người tạo ' tĩnh có lẽ là hạn chế sự kế thừa. Nếu bạn hoặc người dùng thư viện của bạn lấy được một lớp từ bạn Foo, thì Foo::Create()sẽ trở nên vô dụng. Tất cả logic được xác định ở đó sẽ phải được viết lại một lần nữa trong kế thừa Create().

Tôi muốn đề xuất một thỏa hiệp: định nghĩa một hàm tạo với logic khởi tạo đối tượng tầm thường không bao giờ thất bại / ném, sau đó xác định (các) trình tạo với bộ đệm, xây dựng thay thế, v.v. .

Tạo là một phương thức Factory. Khi tôi cảm thấy cần điều này, tôi triển khai mẫu Factory và định nghĩa một giao diện để thể hiện hợp đồng tạo đối tượng cũng như một lớp triển khai, sau đó được đưa vào khi cần thiết. Điều này vẫn giữ được những lợi thế của việc chuyển trách nhiệm sáng tạo ra khỏi lớp, nhưng tránh (hoặc ít nhất là làm rõ hơn) những hạn chế của việc thực hiện tạo đối tượng bên ngoài hàm tạo của lớp.