動的に型付けされた言語の単一の関数から異なるデータ型を返すのは悪い考えですか？

私の第一言語は静的に型付けされています（Java）。Javaでは、すべてのメソッドから単一の型を返す必要があります。たとえば、条件付きでを返すメソッドStringや、条件付きでを返すメソッドを持つことはできませんInteger。しかし、たとえばJavaScriptでは、これは非常に可能です。

静的に型付けされた言語では、これが悪い考えである理由がわかります。すべてのメソッドが返された場合Object（すべてのクラスが継承する共通の親）、あなたとコンパイラはあなたが何を扱っているのか分かりません。実行時にすべての間違いを発見する必要があります。

しかし、動的に型付けされた言語では、コンパイラーさえ存在しない場合があります。動的に型付けされた言語では、複数の型を返す関数が悪い考えである理由は私には明らかではありません。静的言語の私のバックグラウンドにより、このような関数を書くことは避けられますが、コードを見えないようにすっきりさせることができる機能については気にされているのではないかと心配しています。

編集：私の例を削除します（より良い例を考えることができるまで）。私がやろうとしているのではない点に返信するように人々を誘導していると思います。

他の答えとは対照的に、異なる型を返すことが許容される場合があります。

例1

sum(2, 3) → int
sum(2.1, 3.7) → float

一部の静的型付け言語では、これはオーバーロードを伴うため、それぞれが事前定義された固定型を返す複数のメソッドがあると考えることができます。動的言語では、これは同じ機能であり、次のように実装されます。

var sum = function (a, b) {
    return a + b;
};

同じ関数、異なるタイプの戻り値。

例2

OpenID / OAuthコンポーネントから応答を受け取ると想像してください。一部のOpenID / OAuthプロバイダーには、個人の年齢など、より多くの情報が含まれる場合があります。

var user = authProvider.findCurrent();
// user is now:
// {
//     provider: 'Facebook',
//     name: {
//         firstName: 'Hello',
//         secondName: 'World',
//     },
//     email: 'hello.world@example.com',
//     age: 27
// }

他の人は最小限のものを持っているでしょう、それは電子メールアドレスか仮名でしょうか。

var user = authProvider.findCurrent();
// user is now:
// {
//     provider: 'Google',
//     email: 'hello.world@example.com'
// }

繰り返しますが、同じ機能、異なる結果です。

ここで、異なる型を返すことの利点は、型とインターフェイスについては気にしないが、実際にはどのオブジェクトが含まれているかというコンテキストでは特に重要です。たとえば、ウェブサイトに成熟した言語が含まれているとします。次に、findCurrent()このように使用できます：

var user = authProvider.findCurrent();
if (user.age || 0 >= 16) {
    // The person can stand mature language.
    allowShowingContent();
} else if (user.age) {
    // OpenID/OAuth gave the age, but the person appears too young to see the content.
    showParentalAdvisoryRequestedMessage();
} else {
    // OpenID/OAuth won't tell the age of the person. Ask the user himself.
    askForAge();
}

これをコードにリファクタリングすると、すべてのプロバイダーが、明確に定義された固定型を返す独自の機能を持つようになり、コードベースが低下し、コードの重複が発生するだけでなく、メリットもありません。次のような恐怖をすることになります。

var age;
if (['Facebook', 'Yahoo', 'Blogger', 'LiveJournal'].contains(user.provider)) {
    age = user.age;
}

一般に、静的に型付けされた言語の道徳的な同等物が悪い考えであるのと同じ理由で悪い考えです：どの具体的な型が返されるのかわからないので、結果で何ができるかわかりません（任意の値で実行できることはほとんどありません）。静的型システムでは、戻り値の型などのコンパイラーチェックアノテーションがありますが、動的言語でも同じ知識が存在します。ソースコードではなく、脳とドキュメントに非公式で保存されています。

ただし、多くの場合、型が返される韻と理由があり、その効果は静的型システムのオーバーロードまたはパラメトリック多型に似ています。言い換えれば、結果の型は予測可能であり、表現するのはそれほど単純ではありません。

しかし、特定の関数が不適切に設計されている他の理由があるかもしれないことに注意してください：たとえば、sum無効な入力でfalseを返す関数は、主にその戻り値が役に立たずエラーが発生しやすい（0 <-> false混乱）ため、悪い考えです。

動的言語では、異なる型ではなく、異なるAPIを持つオブジェクトを返すかどうかを尋ねるべきではありません。ほとんどの動的言語は実際には型を気にせず、さまざまなバージョンのダックタイピングを使用します。

異なる型を返すときは意味があります

たとえば、このメソッドは理にかなっています：

def load_file(file): 
    if something: 
       return ['a ', 'list', 'of', 'strings'] 
    return open(file, 'r')

ファイルと文字列のリストの両方が（Pythonでは）文字列を返す反復可能オブジェクトであるためです。非常に異なるタイプ、同じAPI（誰かがリストのファイルメソッドを呼び出そうとしない限り、これは別の話です）。

条件付きで返すことができます（listまたはPythonの不変リストです）。tupletuple

正式に行うこと：

def do_something():
    if ...: 
        return None
    return something_else

または：

function do_something(){
   if (...) return null; 
   return sth;
}

Python NoneとJavascriptの両方nullが独自のタイプであるため、異なるタイプを返します。

これらのユースケースはすべて静的言語で対応するものがあり、関数は適切なインターフェイスを返すだけです。

条件に応じて異なるAPIを持つオブジェクトを返すことをお勧めします

異なるAPIを返すことが良いアイデアかどうかについては、ほとんどの場合、IMOは意味をなしません。頭に浮かぶ賢明な例は、@ MainMaが言ったことに近いものです。APIがさまざまな量の詳細を提供できる場合、利用可能な場合により多くの詳細を返すことが理にかなっています。

あなたの質問は私が少し泣きたいです。あなたが提供した使用例ではなく、誰かがこのアプローチを無意識のうちに行き過ぎてしまうためです。それはばかげて保守できないコードから少し離れています。

エラー条件のユースケースの種類は理にかなっており、静的に型付けされた言語のnullパターン（すべてがパターンでなければなりません）は同じタイプのことを行います。関数呼び出しはを返すobjectか、を返しますnull。

ただし、「これを使用してファクトリパターンを作成する」と言って、関数のムードに応じて、fooまたはbarその両方を返すのは簡単ですbaz。これをデバッグすることは、呼び出し側が期待しfooているが与えられたときに悪夢になりbarます。

だから、あなたが心を閉ざしているとは思わない。あなたは言語の機能をどのように使用するかについて適切に注意しています。

開示：私の背景は静的に型付けされた言語であり、一般に、保守可能なコードの必要性がかなり高い、より大きく多様なチームで働いてきました。したがって、私の見方もおそらく歪んでいます。

Javaでジェネリックを使用すると、静的な型の安全性を維持しながら、異なる型を返すことができます。関数呼び出しのジェネリック型パラメーターで返す型を指定するだけです。

Javascriptで同様のアプローチを使用できるかどうかは、もちろん未解決の問題です。Javascriptは動的に型付けされた言語であるため、返さobjectれるのは当然の選択のようです。

静的に型付けされた言語での作業に慣れているときに、動的な戻りシナリオがどこで機能するかを知りたい場合はdynamic、C＃でキーワードを調べることを検討してください。Rob Coneryは、キーワードを使用して、400行のコードでオブジェクトリレーショナルマッパーを正常に記述できましたdynamic。

もちろん、実行時の型の安全性を備えdynamicたobject変数をラップするだけです。

異なる型を条件付きで返すのは悪い考えだと思います。これが私にとって頻繁に出てくる方法の1つは、関数が1つ以上の値を返すことができるかどうかです。値を1つだけ返す必要がある場合、呼び出し関数で値をアンパックする必要を避けるために、値を配列にパックするのではなく、単に値を返すのが妥当と思われる場合があります。ただし、これ（およびこの他のほとんどのインスタンス）は、両方のタイプを区別して処理するために呼び出し元に義務を課します。この関数は、常に同じ型を返すかどうかを簡単に判断できます。

「悪い習慣」は、言語が静的に入力されているかどうかに関係なく存在します。静的言語はこれらの慣行からあなたを遠ざけてくれるので、静的言語はより正式な言語であるため、「悪い慣行」について不満を言うユーザーをより多く見つけるかもしれません。ただし、根本的な問題は動的言語に存在するため、それらが正当化されるかどうかを判断できます。

ここにあなたが提案するものの好ましくない部分があります。返される型がわからない場合、すぐに戻り値を使用することはできません。私はそれについて何かを「発見」しなければなりません。

total = sum_of_array([20, 30, 'q', 50])
if (type_of(total) == Boolean) {
  display_error(...)
} else {
  record_number(total)
}

多くの場合、この種のコードの切り替えは単に悪い習慣です。コードが読みにくくなります。この例では、例外のスローとキャッチが一般的な理由がわかります。別の言い方をすれば、関数が言っていることを実行できない場合、関数は正常に戻りません。あなたの関数を呼び出す場合、これを行いたい：

total = sum_of_array([20, 30, 'q', 50])
display_number(total)

最初の行が正常に返されるため、total実際には配列の合計が含まれていると想定します。正常に戻らない場合は、プログラムの他のページにジャンプします。

エラーの伝播だけではない別の例を使用してみましょう。たぶんsum_of_arrayはスマートになり、「それは私のロッカーの組み合わせです！」配列が[11,7,19]の場合のみ。良い例を考えるのに苦労しています。とにかく、同じ問題が適用されます。何かをする前に、戻り値を調べる必要があります。

total = sum_of_array([20, 30, 40, 50])
if (type_of(total) == String) {
  write_message(total)
} else {
  record_number(total)
}

関数が整数または浮動小数点数を返すことが有用であると主張するかもしれません。例えば：

sum_of_array(20, 30, 40) -> int
sum_of_array(23.45, 45.67, 67.789044) -> float

しかし、あなたが懸念している限り、これらの結果は異なるタイプではありません。あなたはそれらを数字として扱います、そしてそれはあなたが気にするすべてです。したがって、sum_of_arrayは数値型を返します。これがポリモーフィズムです。

そのため、関数が複数の型を返すことができる場合、違反している可能性のある慣行があります。それらを知ることは、特定の関数がとにかく複数の型を返す必要があるかどうかを判断するのに役立ちます。

実際、静的に型付けされた言語であっても、異なる型を返すことはまったく珍しいことではありません。そのため、たとえばユニオン型があります。

実際、Javaのメソッドは、ほとんど常に4つのタイプのいずれかを返します。ある種のオブジェクト、nullまたは例外、またはまったく戻りません。

多くの言語では、エラー条件は、結果タイプまたはエラータイプのいずれかを返すサブルーチンとしてモデル化されます。たとえば、Scalaの場合：

def transferMoney(amount: Decimal): Either[String, Decimal]

もちろんこれは愚かな例です。戻り型は、「文字列または小数を返す」ことを意味します。慣例により、左のタイプはエラータイプ（この場合、エラーメッセージを含む文字列）で、右のタイプは結果のタイプです。

これは例外と似ていますが、例外も制御フローの構成要素であるという事実を除きます。実際、それらは表現力においてに相当しますGOTO。

固体の原則についてはまだ答えがありません。特に、期待される型以外の型を受け取るクラスは、返される型をテストするために何もすることなく、取得したもので動作できるという、リスコフ置換の原則に従う必要があります。

したがって、オブジェクトに追加のプロパティをスローするか、元の関数が目的としていたことを達成する何らかのデコレータで返された関数をラップする場合、関数を呼び出すコードがこれに依存しない限り、あなたは良いですすべてのコードパスでの動作。

文字列または整数を返す代わりに、スプリンクラーシステムまたは猫を返すより良い例があります。これは、呼び出し元のコードがすべてfunctionInQuestion.hiss（）を呼び出すだけの場合に問題ありません。実際には、呼び出し元のコードが予期している暗黙的なインターフェイスがあり、動的に型付けされた言語はインターフェイスを明示的にすることを強制しません。

悲しいことに、同僚はおそらくそうするので、ドキュメントでとにかく同じ作業をする必要があります。ただし、インターフェイスを定義するときのように、普遍的に受け入れられ、簡潔で、機械分析可能な方法はありません。それらを持っている言語で。

私がさまざまなタイプを送信しているのは、無効な入力や、「例外的な」条件がそれほど例外的ではない「貧しい人の例外」の場合です。たとえば、PHPユーティリティ関数の私のリポジトリから、この簡単な例を示します。

function ensure_fields($consideration)
{
        $args = func_get_args();
        foreach ( $args as $a ) {
                if ( !is_string($a) ) {
                        return NULL;
                }
                if ( !isset($consideration[$a]) || $consideration[$a]=='' ) {
                        return FALSE;
                }
        }

        return TRUE;
}

この関数は名目上BOOLEANを返しますが、無効な入力ではNULLを返します。PHP 5.3以降、すべての内部PHP関数も同様に動作することに注意してください。さらに、一部の内部PHP関数は、公称入力でFALSEまたはINTを返します。以下を参照してください。

strpos('Hello', 'e');  // Returns INT(1)
strpos('Hello', 'q');  // Returns BOOL(FALSE)

これは悪い考えではないと思います！この最も一般的な意見とは対照的で、ロバート・ハーベイが既に指摘したように、Javaのような静的型付け言語は、まさにあなたが求めているような状況のためにジェネリックを導入しました。実際、Javaはコンパイル時に（可能な限り）タイプセーフを維持しようとしますが、ジェネリックはコードの重複を避けることがあります。なぜですか？異なる型を処理/返す同じメソッドまたは同じクラスを記述できるためです。このアイデアを示すために、非常に簡単な例を示します。

Java 1.4

public static Boolean getBoolean(String property){
    return (Boolean) properties.getProperty(property);
}
public static Integer getInt(String property){
    return (Integer) properties.getProperty(property);
}

Java 1.5+

public static <T> getValue(String property, Class<T> clazz) throws WhateverCheckedException{
    return clazz.getConstructor(String.class).newInstance(properties.getProperty(property));
}
//the call will be
Boolean b = getValue("useProxy",Boolean.class);
Integer b = getValue("proxyPort",Integer.class);

動的型付き言語では、コンパイル時に型安全性がないため、多くの型で機能する同じコードを自由に記述できます。静的に型付けされた言語でもジェネリックがこの問題を解決するために導入されたので、動的な言語で異なる型を返す関数を書くことは悪い考えではないことは明らかにヒントです。

ソフトウェアの開発は、基本的には複雑さを管理するための芸術であり技術です。余裕のあるポイントでシステムを絞り込み、他のポイントでオプションを制限しようとします。関数のインターフェイスはコントラクトであり、任意のコードを操作するために必要な知識を制限することにより、コードの複雑さを管理するのに役立ちます。さまざまなタイプを返すことにより、返されるさまざまなタイプのすべてのインターフェースを追加し、返されるインターフェースに関する明白でないルールを追加することにより、関数のインターフェースを大幅に拡張します。

関数が行うことはそのコンテキストに依存するため、Perlはこれを頻繁に使用します。たとえば、関数は、リストコンテキストで使用される場合は配列を返し、スカラー値が期待される場所で使用される場合は配列の長さを返すことができます。「perl context」の最初のヒットであるチュートリアルから：

my @now = localtime();

@nowは配列変数（@の意味）であり、（40、51、20、9、0、109、5、8、0）のような配列が含まれます。

代わりに、結果をスカラーにする必要がある方法で関数を呼び出す場合、（$変数はスカラーです）：

my $now = localtime();

その後、まったく異なることを行います。$ nowは、「2009年1月9日金曜日20:51:40」のようになります。

私が考えることができるもう1つの例は、REST APIの実装です。ここでは、返される形式がクライアントの要求に依存します。たとえば、HTML、またはJSON、またはXML。技術的にはこれらはすべてバイトのストリームですが、考え方は似ています。

ダイナミックランドでは、すべてがアヒルのタイピングです。最も責任のある公開された公開されていることは、潜在的に異なるタイプをラッパーでラップして、それらに同じインターフェースを与えることです。

function ThingyWrapper(thingy){ //a function constructor (class-like thingy)

    //thingy is effectively private and persistent for ThingyWrapper instances

    if(typeof thingy === 'array'){
        this.alertItems = function(){
            thingy.forEach(function(el){ alert(el); });
        }
    }
    else {
        this.alertItems = function(){
            for(var x in thingy){ alert(thingy[x]); }
        }
    }
}

function gimmeThingy(){
    var
        coinToss = Math.round( Math.random() ),//gives me 0 or 1
        arrayThingy = [1,2,3],
        objectThingy = { item1:1, item2:2, item3:3 }
    ;

    //0 dynamically evaluates to false in JS
    return new ThingyWrapper( coinToss ? arrayThingy : objectThingy );
}

gimmeThingy().alertItems(); //should be same every time except order of numbers - maybe

ジェネリックラッパーを使用せずにさまざまなタイプを完全に引き出すのが理にかなっている場合がありますが、正直なところ、JSを書いてから7年が経ちました。ほとんどの場合、物事がまとめられているオブジェクトの内部のような閉じた環境のコンテキストで行うことです。しかし、例が思い浮かぶほど頻繁にやったことではありません。

ほとんどの場合、型について考えるのをやめることをお勧めします。動的言語で必要な場合は、型を扱います。もういや。それが全体のポイントです。すべての引数の型をチェックしないでください。それは、同じ方法で明らかでない方法で一貫性のない結果が得られる環境でのみやろうとすることです（そのようなことは絶対にしないでください）。しかし、それは重要なタイプではなく、あなたが私に与えたものがどのように機能するかです。