C＃でメソッドの定義済みのデータ型に対してユーザー定義の戻り値型を持つ利点は何ですか？

Question

メソッドの定義済みデータ型に対する戻り値の型として、class、interface、struct nameのようなユーザー定義の利点はありますか？ 誰かが私に例を挙げてくれればもっと役に立ちます。前もって感謝します。

Answer 1

戻り値の型を変更したい場合や、すでに返されている値に加えて別の値を返す場合は、メソッドを使用してコードを変更する必要はありません。

あなたが望むのは、一般的には大雑把なルールです。しかし、ほとんどのプロジェクトであまり一般的ではなく、実際にそのような変更が必要な場合にのみリファクタリングが行われます。

その理由は、そのようなデザインにはオーバーヘッドがあります - プロジェクトに追加されるクラスや構造が多すぎるため、そのようなラッピングクラスをいつ他の方法でいつ再利用するか、新しいものを作成する。

Answer 2

主な利点は、後で変更を加えることは、改訂しない変更として行うことができることです。

public KeyValuePair<int, String> GetMyStuff(int searchByA, string searchByB) 
{ 
    KeyValuePair<int, String> result = null; 
    //find result using parameters; 
    return result; 
} 

次に、あなたが、あなたはまた、IsActiveプロパティを返す必要があり、それによって検索することができるはず新たな要件を取得想像してみましょう：あなたはメソッドを持っていると仮定します。メソッドのシグネチャを変更する必要があるため、現在の戻り値の型には適合しません。追加のパラメータを追加する前の検索も同様です.APIの変更は大きな変更であり、既存のすべての呼び出し元は、新しい機能が必要ない場合でもリファクタリングする必要があります。

もっと良いアプローチは、入力と出力の概念をカプセル化するために別々のタイプ/インターフェースを持つことです。たとえば：

public class StuffSearchInput 
{ 
    int ByA { get; set; } 
    int ByB { get; set; } 
} 
public class StuffSearchOutput 
{ 
    int Id { get; set; } 
    String Name { get; set; } 
} 
public StuffSearchOutput GetMyStuff(StuffSearchInput arguments) 
{ 
    StuffSearchOutput result = null; 
    //find result using arguments; 
    return result; 
} 

は今、あなたは単に、StuffSearchInputとStuffSearchOutputにIsActiveプロパティを追加することができます方法本体に余分なロジックを追加し、既存の任意の発信者（場所におそらく数百人）を壊すことなく、要件を満たしています。メソッドのシグネチャは変更されず、古い呼び出し元には引き続き対応できます。例：

public class StuffSearchInput 
{ 
    int ByA { get; set; } 
    int ByB { get; set; } 
    Boolean? ByIsActive { get; set; } 
} 
public class StuffSearchOutput 
{ 
    int Id { get; set; } 
    String Name { get; set; } 
    Boolean ByIsActive { get; set; } 
} 
public StuffSearchOutput GetMyStuff(StuffSearchInput arguments) 
{ 
    StuffSearchOutput result = null; 
    //find result using arguments, and also fill the IsActive field. 
    return result; 
} 

インターフェイスを使用すると、許容される入出力を変更する自由がさらに増えます。たとえば、入力としてIEnumerable<T>が必要な場合は、List<T>からCollection<T>までLINQ出力に何かを渡すことができます。

Answer 3

ユーザー定義型は、デザインをより表現しやすく、より厳密に型指定できます。

戻り値の型を組み込み型で保存でき、APIを設計していない場合、APIの改変は気にする必要がありません。余分な式が必要ない場合/ strong typingを入力し、必要に応じて後から変更することができるように、組み込みの型を使用します。

Answer 4

あなたはあなたが何を望んでいるかについてどれだけのことがありますか？アプリケーションロジックがカスタマイズされた一連の情報を返さなければならないと確信している場合は、それを行う必要があります。不明な場合は、不要なオーバーヘッドを避けてください。多形性、特に過負荷を使用する自由が常にあることを忘れないでください。あなたは、異なる種類のパラメータ、理想的にはパラメータの数を変更するために、異なる署名スタンプが必要になります。タイプとパラメータの数が設計上の理由で変更できず、2つ以上のパラメータがあるために過負荷にならない状況がある場合は、タイプが異なると順序位置が変わります。最高ではないが実行可能。いくつか例があります：

public class something 
{ 
    public int MyScore(int subjectID, int attendance, string class name) 
    { 
     //return score 
    } 
    public int[] MyScore(int subjectID, int attendance, string class name, bool includeSportScore) 
    { 
     //return general and sports score here as array 
    } 
    public ScoreQuality MyScore(string xlassName,int subjectID, int attendance) 
    { 
     //return grade instead of number example of changing ordinal position 
    } 

    public enum ScoreQuaity 
    {Average, Poor, Excellent} 
}