2

ジェネリック ライブラリのパブリック API を設計する場合、内部で使用される低レベルのものをどれだけ公開する必要がありますか? 一方では、ユーザーは実装の詳細に過度に依存するべきではなく、低レベルの関数/クラスが多すぎると API が乱雑になる可能性があります。したがって、ひざまずく応答は「なし」である可能性があります。一方、低レベルの機能の一部は人々にとって役立つ可能性があり、それをさらに公開することで、抽象化の逆転 (高レベルの構成の上に低レベルの構成を再実装すること) を防ぐことができます。

さらに、より低レベルの詳細を公開すると、パフォーマンスのショートカットが提供される可能性があります。たとえば、配列の中央値を求める関数があるとします。最小驚きの原則では、配列を複製して、API のユーザーがその実装に要素の並べ替えの副作用が伴うことを気にする必要がないようにする必要があります。この場合、 median() はメモリ割り当てを必要とし、割り当てをバイパスする別の関数を提供するが、ユーザーの入力を任意に並べ替えることに注意する必要がありますか?

この種の詳細をどの程度公開するかについての一般的なガイドラインは何ですか?

4

4 に答える 4

2

できるだけ少なく。

公開する詳細が多いほど、変更によって消費者が壊れる可能性が高くなります。

于 2009-01-10T14:44:59.770 に答える
2

API では、呼び出し元が内部の状態をいじって何かを「壊す」ことを許可してはなりません (たとえば、コレクションの並べ替えなど)。この問題を解決するには、公開されたインターフェイスを必要なときにのみ読み取る必要があります。

複雑さに関しては、単純で基本的な方法に傾倒しています。私は、今後必要になると思われるものを過度に設計しないように努めています。

今日の要件 (おそらく明日の要件) に合わせて書きますが、それを超える必要はありません。将来的にはいつでも延長できます。維持できなくなったものを単に落とすのは、はるかに困難です。

于 2009-01-10T14:47:19.577 に答える
1

それを行うUNIXの方法は、ポリシーではなくメカニズムを提供することです。物事を行うための適切なツール (ナイフなど) を提供するだけで、それらがどのように使用されるか (リンゴの皮をむく、または鉛筆を削る) を予測しないようにしてください。

于 2009-01-10T15:00:18.523 に答える
1

私がそれを表現したのを聞いたことがあります: whatを公開しますが、 howは公開しません。

目標は、ライブラリの内部構造にクライアントを依存させることなく、クライアントが使用できる便利で豊富なライブラリを提供することです。呼び出し元を壊すことなく、内部を変更できるようにしたい (他の誰かが既に指摘したように)。

優れた API を作成するには、ある程度の巧妙な瀬戸際技術が必要です。

于 2009-01-10T20:24:18.103 に答える