メソッドのパラメーター型、戻り値の型、およびプロパティ型の具体性に関する規則

少し前に、メソッドパラメータの型、戻り値の型、およびプロパティの型の具体性についての「経験則」を読みましたが、覚えていません。

それはあなたの戻り値の型をできるだけ具体的にそしてあなたのパラメータ型をできるだけ抽象的に保つことについて何かを言った...またはその逆

実際に良いアドバイスなのか悪いアドバイスなのかはわかりませんので、ご自身の考えがあればコメントしてください。

乾杯。

これ以上は必要ありません、それ以上は約束しません。

このフレーズは、ベルトランマイヤーが先駆けて開発した「Design by Contract」のアイデアに由来しています。

http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract

「リスコフ置換原理」も参照してください

/programming/56860/what-is-the-liskov-substitution-principle

抽象的な入力と具体的な出力があると、関数がより一般的になります。これは、より多くの方法で使用できることを意味します。一方、それはあなたのメソッドのより強い制約を課し、それの将来の実装がどのように機能するかを制限します。したがって、それは異なる目標間のトレードオフです。

それはあなたがポステルの法則の外挿を聞いたかもしれません：「あなたが送るものに保守的で、あなたが受け入れるものに寛大に」。

ほとんどの場合、コードの再利用性を最大化することです。なぜそれが役立つのかを示すためにケースを考え出すのは簡単です。Iterable<T>例としてJavaを考えます。メソッドがすべてのTsを反復処理することだけである場合、Iterable<T>パラメータータイプとしてを使用すると、インターフェイスを実装するカスタムクラスは言うまでもなく、60以上の組み込みクラスでそのメソッドを使用できます。たとえば、に制限した場合Vector<T>、メソッドを呼び出すコードはすべてVector<T>最初のコードに変換する必要があります。

一方、返すIterable<T>メソッドからは取るものにあなたの戻り値を使用することができ、コード量制限Iterable<T>パラメータを。あなたは非常に具体的な型を返す場合は、のようにVector<T>、そしてあなたの戻り値は取る任意のメソッドに渡すことができSerializable、Cloneable、Iterable<T>、Collection<T>、List<T>、RandomAccess、Vector<T>、AbstractList<T>、またはAbstractCollection<T>、そして期待どおりに動作します。