Khi nào một tham số `out` được sử dụng thay vì trả về một kiểu phức?

Question

Khi nào chúng ta nên sử dụng tham số out trong C#?

Ví dụ

bool TryGetValue(out object value); 

vs

class ReturnType 
{ 
     public bool Found {get;set;} 
     public object Value {get;set;} 
} 

ReturnType TryGetValue(); 

Ngoài việc giảm số lượng các dòng mã, khi cần một tham số out được sử dụng và khi nó nên được trả lại như kiểu trả về?

Answer 1

Ngoài ra cũng có thể được sử dụng cho các hoạt động có thể không thành công (thường được tìm thấy trong các phương pháp bắt đầu thử *).

Ví dụ: TryParse sẽ trả về một bool cho biết thành công/thất bại trong khi sử dụng giá trị ngoài là kết quả. Điều này tránh phải ném ngoại lệ.

Answer 2

Nếu đối tượng có thể rỗng. Không cần phải instatiate sau đó.

Answer 3

Bạn đã đóng đinh chính xác lý do tại sao nó nên được sử dụng. Để giảm độ phức tạp của mã.

if (TryGetValue(myObj)) 
{ 
    [...] 
} 

là hơn gọn gàng hơn

Result tryGetValueResult = TryGetValue(); 
if (tryGetValueResult.Found) 
{ 
    [...] 
} 

Nó cũng có thể tiết kiệm rác khi kết quả cần phải được một loại tài liệu tham khảo.

Answer 4

Nếu không có lý do chung để đóng gói nhiều giá trị cùng nhau, khác với cuộc gọi này, thì việc tạo một loại riêng biệt có thể là trên đầu. Mặt khác, nếu bạn có nhiều tham số và giá trị trả về mà tất cả đều thuộc về nhau (ví dụ: tên, họ, số điện thoại) thì có thể tạo ra một kiểu thích hợp (vd: "Liên hệ ") và trả lại điều đó.

Một lựa chọn thay thế cho tùy chọn TryGetValue là sử dụng các loại giá trị có thể vô hiệu hóa, nếu giá trị được đề cập là là một loại giá trị. Ví dụ, int.TryParse có thể đã có một chữ ký của:

int? TryParse(string text) 

(với một tình trạng quá tải tham gia một IFormatProvider tất nhiên).

Answer 5

Chúng hữu ích trong trường hợp (hiếm) bạn cần trả lại giá trị từ một hàm tạo. Ví dụ: hàm tạo Mutex có tham số boolean được đặt để cho biết liệu một Mutex mới đã được tạo hay chưa tồn tại một mutex hiện có với tên đã tồn tại.

Answer 6

Tôi sẽ bỏ phiếu cho việc sử dụng loại trả lại. Mặc dù C# không phải là một ngôn ngữ chức năng, tôi nghĩ rằng nó tốt để nhắm vào một phong cách lập trình chức năng. Không dành cho sự thuần khiết học thuật, nhưng đối với những lợi ích thực dụng, nơi mà hành vi của mọi chức năng là không bí ẩn, không có tác dụng phụ.

Answer 7

Nếu bạn mong đợi hàm của mình chỉ trả về tham chiếu đến đối tượng đang thoát hoặc tạo đối tượng mới thì chỉ sử dụng tham số ngoài.

Answer 8

Tôi thích đặt giá trị trả lại cho các chỉ số thành công.Hoặc là đúng/sai đơn giản để thành công hoặc điều gì phức tạp hơn như 0 để thành công và các giá trị khác cho biết lỗi là gì.

Điều này có nghĩa là một lập trình viên có thể kiểm tra thành công trên mọi chức năng bạn viết. (tất nhiên, không phải tất cả, nhưng có thể)

Thông số này sau đó yêu cầu tham số để truy xuất giá trị từ hàm.

Answer 9

Từ khóa ngoài thực thi một vài điều thông qua trình biên dịch ..
Người gọi không phải khởi tạo thông số. Các callee không thể đọc từ param nhưng phải viết cho nó trước khi thoát khỏi phương thức.

ra quan trọng hơn làm cho mục đích có thể nhìn thấy như người gọi có để xác định từ khóa ra khi thực hiện một cuộc gọi phương thức

Bạn có thể sử dụng ra khi bạn cần phải trả về nhiều giá trị từ một phương pháp (không có nhồi và tiêu diệt chúng từ một đối tượng []). (Phần yêu thích trả lại bSuccess từ mọi chức năng sẽ yêu thích từ khóa.)
Trong ví dụ mà bạn đã đăng .. Giá trị trả về chính của TryParse là thành công của hoạt động phân tích cú pháp. Vì vậy, đó là giá trị trả về - nhưng nhu cầu tiếp theo có thể xảy ra nhất là lấy đối tượng được phân tích cú pháp nếu nó thành công. Vì vậy, thay vì làm cho tất cả người gọi thực hiện bước đó, TryParse tiết kiệm cho bạn sự cố bằng cách cho nó như là một tham số ngoài .. vì nó đã thực hiện điều đó như một phần của kiểm tra CanParse.

Answer 10

Thông số ngoài thường ở phía giòn. Di chuyển ra ngoài ví dụ, và nhìn vào vấn đề nói chung: Sách của Bill Wagner "Hiệu quả hơn C#" mô tả một cách tiếp cận thông minh cho điều này, nó cũng được mô tả chi tiết here.

Mã sau đây sẽ hoạt động trong trường hợp này.

public class Tuple<T1,T2> 
{ 
    public T1 First {get;private set;} 
    public T2 Second {get; private set;} 
    Tuple(T1 first, T2 second) 
    { 
    First = first; 
    Second = second; 
    } 
} 


using ComplexPair = Tuple<bool,object>; 

public class SomeOtherClass 
{ 
    public ComplexPair GetComplexType() 
    { 
    ... 
    return new ComplexPair(true, new object); 

    } 
} 

Answer 11

Trong openion của tôi cả hai đều đúng, tuy nhiên tôi thấy trở về một loại phức tạp thêm thanh lịch đặc biệt là nếu nó là một kiểu generic

ReturnType<T> 

này cho biết thêm thông tin về những gì mong đợi giá trị sẽ được, do đó bạn không đoán loại Giá trị gốc và thực hiện truyền.

Answer 12

Sẽ tốt hơn nếu bạn sử dụng một loại tùy chọn như một loại tùy chọn làm vùng chứa cho các loại trả lại có thể không có. Đây là phổ biến trong hầu hết các ngôn ngữ chức năng như Scala. Hữu ích cho trường hợp bạn chỉ quan tâm đến việc có thành công hay thất bại, và bạn không quan tâm lý do tại sao. ví dụ. Phân tích số nguyên.

int num; // mutable = bugprone 
if (!int.TryParse(str, out num)) // branching = complexity 
    num = someDefault; 

Sử dụng loại tùy chọn, bạn có thể xác định trình phân tích cú pháp bao gồm độ xấu có thể thay đổi và trả về tùy chọn rõ ràng. điều này làm giảm sự phức tạp của bạn bằng cách có điều này nếu chỉ trong MỘT NƠI NƠI. tránh trùng lặp và đột biến.

public Option<int> IntParse(string str) { 
    int num; // mutable 
    if (!int.TryParse(str, out num)) 
     return Option.None<int>(); 
    else 
     return Option.Some<int>(num); 
    } 

sử dụng ở những nơi khác:

int result = IntParse(someString).GetOrElse(defaultValue); 

Như bạn có thể thấy kết quả này trong một mô hình sử dụng cách đo ít phức tạp, kể từ nhánh đã bị ẩn.

Cách khác, nếu chức năng của bạn đã trở lại hai điều, đó là một cơ hội mà:

• Chức năng là quá phức tạp và cần được chia ra (làm một việc tốt!), Hoặc
• Các giá trị trả về có liên quan chặt chẽ và phải được liên kết với nhau theo một loại mới

Nội dung cần suy nghĩ!