Tại sao có một phương thức trả về bool / int và có đối tượng thực tế làm tham số đầu ra?

Tôi thấy mẫu mã sau đây xuất hiện ở khắp nơi trong cơ sở mã của công ty tôi (ứng dụng .NET 3.5):

bool Foo(int barID, out Baz bazObject) { 
    try { 
            // do stuff
            bazObject = someResponseObject;

            return true;
    }
    catch (Exception ex) { 
        // log error
        return false;
    }
}

// calling code
BazObject baz = new BazObject();
fooObject.Foo(barID, out baz);

if (baz != null) { 
    // do stuff with baz
}

Tôi đang cố gắng che giấu lý do tại sao bạn sẽ làm điều này thay vì Foophương thức chỉ cần lấy ID và trả về một Bazđối tượng, thay vì trả về một giá trị không được sử dụng và có đối tượng thực tế là tham số đầu ra hoặc tham số đầu ra.

Có một số lợi ích tiềm ẩn của phong cách mã hóa này mà tôi đang thiếu?

Bạn thường sử dụng mẫu đó để bạn có thể viết mã như thế này:

if (Foo(barId, out bazObject))
{
  //DoStuff with bazobject
}

ví dụ, nó được sử dụng trong CLR cho TryGetValue trong lớp từ điển. Nó tránh được một số dư thừa nhưng các tham số out và ref luôn có vẻ hơi lộn xộn với tôi

Đây là mã kiểu C cũ, trước khi có ngoại lệ. Giá trị trả về cho biết phương thức có thành công hay không và nếu có, tham số sẽ được điền với kết quả.

Trong .net, chúng tôi có ngoại lệ cho mục đích đó. Không nên có lý do để theo mô hình này.

[sửa] Rõ ràng có ý nghĩa về hiệu suất trong xử lý ngoại lệ. Có thể là có cái gì đó để làm với nó. Tuy nhiên, trong đoạn mã đó đã có một ngoại lệ được đưa ra. Sẽ tốt hơn nếu chỉ để nó di chuyển lên ngăn xếp cho đến khi nó bị bắt ở một nơi thích hợp hơn.

Với đoạn mã, nó trông hoàn toàn vô nghĩa. Đối với tôi, mẫu mã ban đầu sẽ gợi ý rằng null cho BazObject sẽ là một trường hợp có thể chấp nhận được và trả về bool là một biện pháp xác định trường hợp thất bại một cách an toàn. Nếu đoạn mã sau là:

// calling code
BazObject baz = new BazObject();
bool result = fooObject.Foo(barID, out baz);

if (result) { 
    // do stuff with baz
    // where baz may be 
    // null without a 
    // thrown exception
}

Điều này sẽ có ý nghĩa hơn với tôi để làm theo cách này. Có lẽ đây là một phương thức mà ai đó trước khi bạn sử dụng để đảm bảo rằng baz được truyền qua tham chiếu mà không hiểu làm thế nào các tham số đối tượng thực sự hoạt động trong C #.

Đôi khi mẫu này hữu ích khi bạn, người gọi, không cần quan tâm xem loại trả về là loại tham chiếu hay loại giá trị. Nếu bạn đang gọi một phương thức như vậy để truy xuất một loại giá trị, loại giá trị đó sẽ cần một giá trị không hợp lệ được thiết lập (ví dụ: double.NaN) hoặc bạn cần một số cách khác để xác định thành công.

Ý tưởng là trả về một giá trị cho biết liệu quy trình có thành công hay không, cho phép mã như thế này:

Baz b;
if (fooObject.foo(id, out b)) {
   // do something with b
}
else {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

Nếu đối tượng không thể là null (có vẻ đúng trong ví dụ của bạn), thì tốt hơn nên làm như sau:

Baz b = fooObject.foo(id);
if (b != null) {
   // do something with b
}
else {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

Nếu đối tượng có thể là null, ngoại lệ là cách để đi:

try {
   Baz b = fooObject.foo(id);
}
catch (BazException e) {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

Đó là một mô hình phổ biến được sử dụng trong C, nơi không có ngoại lệ. Nó cho phép hàm trả về một điều kiện lỗi. Ngoại lệ nói chung là một giải pháp sạch hơn nhiều.