Cái nào tốt hơn, trả về giá trị hoặc tham số out?

Nếu chúng ta muốn nhận một giá trị từ một phương thức, chúng ta có thể sử dụng giá trị trả về, như sau:

public int GetValue(); 

hoặc là:

public void GetValue(out int x);

Tôi không thực sự hiểu sự khác biệt giữa chúng và vì vậy, không biết cái nào tốt hơn. Bạn có thể giải thích cho tôi điều này?

Cảm ơn bạn.

Các giá trị trả về hầu như luôn là lựa chọn đúng khi phương thức không có gì khác để trả về. (Trong thực tế, tôi không thể nghĩ ra bất kỳ trường hợp tôi muốn bao giờ muốn có một phương pháp khoảng trống với một outtham số, nếu tôi có sự lựa chọn. C # 7 Deconstructphương pháp để giải cấu trúc ngôn ngữ được hỗ trợ đóng vai trò như một ngoại lệ rất, rất hiếm đối với quy tắc này .)

Ngoài bất cứ điều gì khác, nó ngăn người gọi phải khai báo biến riêng:

int foo;
GetValue(out foo);

đấu với

int foo = GetValue();

Các giá trị out cũng ngăn chặn chuỗi phương thức như thế này:

Console.WriteLine(GetValue().ToString("g"));

(Thật vậy, đó cũng là một trong những vấn đề với setters tài sản, và đó là lý do tại sao mẫu trình xây dựng sử dụng các phương thức trả về trình tạo, ví dụ myStringBuilder.Append(xxx).Append(yyy).)

Ngoài ra, các tham số out hơi khó sử dụng với sự phản chiếu và thường làm cho việc kiểm tra cũng khó hơn. (Nhiều nỗ lực hơn thường được đưa vào để dễ dàng giả định các giá trị trả về hơn các tham số ngoài). Về cơ bản không có gì tôi có thể nghĩ rằng họ làm cho dễ dàng hơn ...

Trả về giá trị FTW.

EDIT: Xét về những gì đang diễn ra ...

Về cơ bản khi bạn truyền vào một đối số cho tham số "out", bạn phải truyền vào một biến. (Các phần tử mảng cũng được phân loại là biến.) Phương thức bạn gọi không có biến "mới" trên ngăn xếp của nó cho tham số - nó sử dụng biến của bạn để lưu trữ. Bất kỳ thay đổi trong biến được nhìn thấy ngay lập tức. Đây là một ví dụ cho thấy sự khác biệt:

using System;

class Test
{
    static int value;

    static void ShowValue(string description)
    {
        Console.WriteLine(description + value);
    }

    static void Main()
    {
        Console.WriteLine("Return value test...");
        value = 5;
        value = ReturnValue();
        ShowValue("Value after ReturnValue(): ");

        value = 5;
        Console.WriteLine("Out parameter test...");
        OutParameter(out value);
        ShowValue("Value after OutParameter(): ");
    }

    static int ReturnValue()
    {
        ShowValue("ReturnValue (pre): ");
        int tmp = 10;
        ShowValue("ReturnValue (post): ");
        return tmp;
    }

    static void OutParameter(out int tmp)
    {
        ShowValue("OutParameter (pre): ");
        tmp = 10;
        ShowValue("OutParameter (post): ");
    }
}

Các kết quả:

Return value test...
ReturnValue (pre): 5
ReturnValue (post): 5
Value after ReturnValue(): 10
Out parameter test...
OutParameter (pre): 5
OutParameter (post): 10
Value after OutParameter(): 10

Sự khác biệt là ở bước "bài" - tức là sau khi biến cục bộ hoặc tham số đã được thay đổi. Trong thử nghiệm ReturnValue, điều này không tạo ra sự khác biệt với valuebiến tĩnh . Trong thử nghiệm OutParameter, valuebiến được thay đổi bởi dòngtmp = 10;

Những gì tốt hơn, phụ thuộc vào tình hình cụ thể của bạn. Một trong những lý do outtồn tại là để tạo điều kiện trả về nhiều giá trị từ một lệnh gọi phương thức:

public int ReturnMultiple(int input, out int output1, out int output2)
{
    output1 = input + 1;
    output2 = input + 2;

    return input;
}

Vì vậy, một định nghĩa không tốt hơn so với định nghĩa khác. Nhưng thông thường, bạn muốn sử dụng một khoản hoàn trả đơn giản, trừ khi bạn có tình huống trên chẳng hạn.

EDIT: Đây là một mẫu chứng minh một trong những lý do mà từ khóa tồn tại. Trên đây là không có cách nào để được coi là một thực hành tốt nhất.

Bạn thường nên thích một giá trị trả về hơn một param. Thông số ra là một điều ác cần thiết nếu bạn thấy mình viết mã cần làm 2 việc. Một ví dụ điển hình cho điều này là mẫu Thử (như Int32.TryPude).

Hãy xem xét người gọi hai phương thức của bạn sẽ phải làm gì. Ví dụ đầu tiên tôi có thể viết điều này ...

int foo = GetValue();

Lưu ý rằng tôi có thể khai báo một biến và gán nó thông qua phương thức của bạn trong một dòng. Ví dụ thứ 2 nó trông như thế này ...

int foo;
GetValue(out foo);

Bây giờ tôi buộc phải khai báo biến của mình lên phía trước và viết mã của mình qua hai dòng.

cập nhật

Một nơi tốt để xem khi hỏi những loại câu hỏi này là Nguyên tắc Thiết kế .NET Framework. Nếu bạn có phiên bản sách thì bạn có thể thấy các chú thích của Anders Hejlsberg và những người khác về chủ đề này (trang 184-185) nhưng phiên bản trực tuyến ở đây ...

http://msdn.microsoft.com/en-us/l Library / ms182131 (VS.80) .aspx

Nếu bạn thấy mình cần trả lại hai thứ từ một API thì việc gói chúng trong một cấu trúc / lớp sẽ tốt hơn một tham số ngoài.

Có một lý do để sử dụng một thông outsố chưa được đề cập: phương thức gọi có nghĩa vụ phải nhận nó. Nếu phương thức của bạn tạo ra một giá trị mà người gọi không nên loại bỏ, làm cho nó trở thành một outngười gọi phải chấp nhận cụ thể:

 Method1();  // Return values can be discard quite easily, even accidentally

 int  resultCode;
 Method2(out resultCode);  // Out params are a little harder to ignore

Tất nhiên người gọi vẫn có thể bỏ qua giá trị trong một outparam, nhưng bạn đã gọi sự chú ý của họ đến nó.

Đây là một nhu cầu hiếm có; thường xuyên hơn, bạn nên sử dụng một ngoại lệ cho một vấn đề thực sự hoặc trả lại một đối tượng có thông tin trạng thái cho "FYI", nhưng có thể có trường hợp điều này rất quan trọng.

Đó là sở thích chủ yếu

Tôi thích trả về và nếu bạn có nhiều lợi nhuận, bạn có thể gói chúng trong Kết quả DTO

public class Result{
  public Person Person {get;set;}
  public int Sum {get;set;}
}

Bạn chỉ có thể có một giá trị trả về trong khi bạn có thể có nhiều tham số.

Bạn chỉ cần xem xét các tham số trong những trường hợp đó.

Tuy nhiên, nếu bạn cần trả về nhiều hơn một tham số từ phương thức của mình, bạn có thể muốn xem những gì bạn đang trả về từ cách tiếp cận OO và xem xét liệu bạn có nên trả lại một đối tượng hoặc một cấu trúc với các tham số này không. Do đó, bạn trở lại giá trị trả lại một lần nữa.

Bạn hầu như luôn luôn nên sử dụng giá trị trả về. Các outtham số '' tạo ra một chút ma sát với rất nhiều API, thành phần, v.v.

Ngoại lệ đáng chú ý nhất xuất hiện trong đầu là khi bạn muốn trả về nhiều giá trị (.Net Framework không có bộ dữ liệu cho đến 4.0), chẳng hạn như với TryParsemẫu.

Tôi thích cái sau thay vì một trong những cái trong ví dụ đơn giản này.

public int Value
{
    get;
    private set;
}

Nhưng, tất cả chúng đều rất giống nhau. Thông thường, người ta sẽ chỉ sử dụng 'out' nếu họ cần truyền lại nhiều giá trị từ phương thức. Nếu bạn muốn gửi một giá trị vào và ra khỏi phương thức, người ta sẽ chọn 'ref'. Phương pháp của tôi là tốt nhất, nếu bạn chỉ trả về một giá trị, nhưng nếu bạn muốn truyền tham số và lấy lại giá trị, bạn có thể chọn lựa chọn đầu tiên.

Tôi nghĩ rằng một trong số ít trường hợp sẽ hữu ích khi làm việc với bộ nhớ không được quản lý và bạn muốn làm rõ rằng giá trị "được trả về" nên được xử lý theo cách thủ công, thay vì tự xử lý nó .

Ngoài ra, các giá trị trả về tương thích với các mô hình thiết kế không đồng bộ.

Bạn không thể chỉ định một chức năng "không đồng bộ" nếu nó sử dụng tham số ref hoặc out.

Tóm lại , Giá trị trả về cho phép kết nối phương thức, cú pháp sạch hơn (bằng cách loại bỏ sự cần thiết cho người gọi để khai báo các biến bổ sung) và cho phép thiết kế không đồng bộ mà không cần sửa đổi đáng kể trong tương lai.

Cả hai đều có một mục đích khác nhau và không được trình biên dịch đối xử giống nhau. Nếu phương thức của bạn cần trả về một giá trị, thì bạn phải sử dụng return. Out được sử dụng khi phương thức của bạn cần trả về nhiều giá trị.

Nếu bạn sử dụng return, thì dữ liệu trước tiên được ghi vào ngăn xếp phương thức và sau đó trong phương thức gọi. Trong trường hợp hết, nó được ghi trực tiếp vào ngăn xếp phương thức gọi. Không chắc chắn nếu có thêm sự khác biệt.

Như những người khác đã nói: giá trị trả lại, không ra param.

Tôi có thể giới thiệu cho bạn cuốn sách "Nguyên tắc thiết kế khung" (tái bản lần 2) không? Trang 184-185 bao gồm các lý do để tránh các thông số. Toàn bộ cuốn sách sẽ giúp bạn đi đúng hướng trong tất cả các loại vấn đề mã hóa .NET.

Đồng minh với Nguyên tắc thiết kế khung là việc sử dụng công cụ phân tích tĩnh, FxCop. Bạn sẽ tìm thấy điều này trên các trang web của Microsoft dưới dạng tải xuống miễn phí. Chạy mã này trên mã được biên dịch của bạn và xem những gì nó nói. Nếu nó phàn nàn về hàng trăm và hàng trăm thứ ... đừng hoảng sợ! Hãy bình tĩnh và cẩn thận với những gì nó nói về từng trường hợp. Đừng vội vàng sửa chữa mọi thứ càng sớm càng tốt. Học hỏi từ những gì nó đang nói với bạn. Bạn sẽ được đưa vào con đường để làm chủ.

Sử dụng từ khóa out với loại bool trả về, đôi khi có thể làm giảm sự phình mã và tăng khả năng đọc. (Chủ yếu khi thông tin bổ sung trong thông số ngoài thường bị bỏ qua.) Ví dụ:

var result = DoThing();
if (result.Success)
{
    result = DoOtherThing()
    if (result.Success)
    {
        result = DoFinalThing()
        if (result.Success)
        {
            success = true;
        }
    }
}

vs

var result;
if (DoThing(out result))
{
    if (DoOtherThing(out result))
    {
        if (DoFinalThing(out result))
        {
            success = true;
        }
    }
}

Không có sự khác biệt thực sự. Các tham số out nằm trong C # để cho phép phương thức trả về nhiều hơn một giá trị, đó là tất cả.

Tuy nhiên, có một số khác biệt nhỏ, nhưng không phải trong số chúng thực sự quan trọng:

Sử dụng tham số out sẽ bắt buộc bạn sử dụng hai dòng như:

int n;
GetValue(n);

trong khi sử dụng giá trị trả về sẽ cho phép bạn thực hiện trong một dòng:

int n = GetValue();

Một điểm khác biệt (chỉ đúng với các loại giá trị và chỉ khi C # không thực hiện hàm) là việc sử dụng giá trị trả về sẽ nhất thiết phải tạo một bản sao của giá trị khi hàm trả về, trong khi sử dụng tham số OUT sẽ không nhất thiết phải làm như vậy.

out hữu ích hơn khi bạn đang cố trả về một đối tượng mà bạn khai báo trong phương thức.

Thí dụ

public BookList Find(string key)
{
   BookList book; //BookList is a model class
   _books.TryGetValue(key, out book) //_books is a concurrent dictionary
                                     //TryGetValue gets an item with matching key and returns it into book.
   return book;
}

giá trị trả về là giá trị bình thường được trả về bởi phương thức của bạn.

Trong trường hợp tham số out out , well out và ref là 2 từ khóa của C #, chúng cho phép truyền các biến làm tham chiếu .

Sự khác biệt lớn giữa ref và out là, ref nên được khởi tạo trước và sau không

Tôi nghi ngờ tôi sẽ không xem xét câu hỏi này, nhưng tôi là một lập trình viên rất có kinh nghiệm và tôi hy vọng một số độc giả cởi mở hơn sẽ chú ý.

Tôi tin rằng nó phù hợp với các ngôn ngữ lập trình hướng đối tượng tốt hơn cho các thủ tục trả về giá trị (VRP) của chúng là mang tính xác định và thuần túy.

'VRP' là tên học thuật hiện đại cho một hàm được gọi là một phần của biểu thức và có giá trị trả về thay thế cho cuộc gọi trong khi đánh giá biểu thức. Ví dụ, trong một tuyên bố như x = 1 + f(y)hàm fđang phục vụ như một VRP.

'Xác định' có nghĩa là kết quả của hàm chỉ phụ thuộc vào các giá trị của tham số. Nếu bạn gọi nó một lần nữa với cùng các giá trị tham số, bạn chắc chắn sẽ nhận được kết quả tương tự.

'Pure' có nghĩa là không có tác dụng phụ: gọi hàm không làm gì ngoài việc tính toán kết quả. Điều này có thể được hiểu là không có tác dụng phụ quan trọng , trong thực tế, do đó, nếu VRP xuất ra một thông báo gỡ lỗi mỗi khi nó được gọi, ví dụ, điều đó có thể bị bỏ qua.

Do đó, nếu trong C #, hàm của bạn không xác định và thuần túy, tôi nói bạn nên biến nó thành voidhàm (nói cách khác, không phải VRP) và bất kỳ giá trị nào nó cần trả về phải được trả về trong một outhoặc một reftham số.

Ví dụ: nếu bạn có chức năng xóa một số hàng khỏi bảng cơ sở dữ liệu và bạn muốn nó trả về số lượng hàng đã xóa, bạn nên khai báo nó như sau:

public void DeleteBasketItems(BasketItemCategory category, out int count);

Nếu đôi khi bạn muốn gọi hàm này nhưng không nhận được count, bạn luôn có thể khai báo quá tải.

Bạn có thể muốn biết tại sao phong cách này phù hợp với lập trình hướng đối tượng tốt hơn. Nhìn rộng ra, nó phù hợp với một phong cách lập trình có thể (một chút không chính xác) được gọi là "lập trình thủ tục", và đó là một phong cách lập trình thủ tục phù hợp với lập trình hướng đối tượng tốt hơn.

Tại sao? Mô hình cổ điển của các đối tượng là chúng có các thuộc tính (còn gọi là thuộc tính), và bạn thẩm vấn và thao tác đối tượng (chủ yếu) thông qua việc đọc và cập nhật các thuộc tính đó. Một kiểu lập trình thủ tục có xu hướng làm cho việc này dễ dàng hơn, bởi vì bạn có thể thực thi mã tùy ý ở giữa các hoạt động nhận và đặt thuộc tính.

Nhược điểm của lập trình thủ tục là bởi vì bạn có thể thực thi mã tùy ý ở mọi nơi, bạn có thể nhận được một số tương tác rất khó hiểu và dễ bị lỗi thông qua các biến toàn cầu và tác dụng phụ.

Vì vậy, khá đơn giản, đó là một thực tiễn tốt để báo hiệu cho ai đó đọc mã của bạn rằng một hàm có thể có tác dụng phụ bằng cách làm cho nó không trả về giá trị.