3

顧客がアクセス可能なAPIを定義する場合、次の中で推奨される業界慣行は何ですか。

a）それぞれが非常に狭く特定の目的を持つ一連の明示的なAPIメソッドを定義します。次に例を示します。

SetUserName    <name>
SetUserAge     <age>
SetUserAddress <address>

b）より一般化されたパラメータベースのAPIメソッドのセットを定義します。例：

SetUserAttribute <attribute>

enum attribute {
    name,
    age,
    address
}

私の意見：

（a）に賛成

ブールベースのメソッド（EnableFooなど）の場合、意図がはるかに明確であり、将来拡張が必要になる可能性が低く、コードが読みやすくなるため、オプション（a）を明確に優先します。

たとえば、EnableDisableFooと呼ばれるメソッドは、有効にするか無効にするかを示すブールパラメータを取りますが、あまり明確ではなく、まとまりのある目的もありません。

問題がより複雑になるのは、複数のオプションがある場所です。

（b）に賛成

オプション（b）は、APIに拡張性を提供する優れた方法ですが、使いやすさが犠牲になります。オプション（a）を使用すると、APIメソッド名自体が、それが何をしているかを示すのに十分な情報を提供します。オプション（b）を使用すると、ユーザーはメソッド名と使用する適切な列挙/パラメーターの両方を検索する必要があります。理論的には、これはユーザビリティの観点からオプション（b）を悪化させますが、メソッドを少なくすることは良いことなので、これでも完全には当てはまりません。

他の考え

使いやすさと拡張性のバランスをとる必要があり、それらはしばしば互いに対立しています。しかし、APIデザイナーの意見に頼るのではなく、これを分析するためのより客観的な方法があると思います。

誰かがこれについて何か考えを持っていますか？

4

3 に答える 3

2

私たちの目標は「静的」コードを可能な限り正確で信頼できるものにすることなので、私は個人的に（a）について議論します。

一般化された形式を使用することにより、実行時エラーのリスクが発生します。たとえば、実際には文字列である値を使用して、age型の属性を設定できます。

これは、もう1つのレベルの保証が得られるため、古いCスタイルでintを使用して返すのではなく、列挙型または明示的な型を定義して使用するための引数と非常によく似ています。

（b）が拡張性を許可することに同意しますが、完全に異なるタイプの属性に対してこの種の拡張性を必要とするAPIはあまり多くありません。（b）の唯一の一般的な使用法は、関数が拡張機能を含むあらゆるものを技術的に受け入れることができるポリモルフィックコードです。

于 2009-01-28T05:42:15.530 に答える
1

もう1つの考慮事項は、すべての属性を設定し、それらを同時に設定するかどうかです。たとえば、プリンタに何かを送信する場合、設定するパラメータが数十ある場合があります（横向きまたは縦向き、部数、ページサイズ、解像度など）。何十回も呼び出す必要のあるAPIを定義する代わりに、をstructパラメーターとして受け取り、struct何十ものフィールドが含まれ、呼び出し元が自由に初期化してstructから、を渡す単一の関数を定義できます。struct単一の関数呼び出しでAPIに接続します。

于 2009-01-28T05:47:07.830 に答える
0

書いているコードにもよると思います。常に一緒になるものについて書いている場合 (つまり、年齢を常に名前と一緒に使用/変更する場合)、b に進みます。それ以外の場合は a で問題ありません。

ただし、(a) を過度に実行しようとしないでください。そうすると、より多くの行を記述して、はるかに少ない成果しか得られなくなります。あなたが書いたコードの量に対して支払われるなら、良い考えです:)

于 2009-01-28T06:45:32.377 に答える