事業独立から
事業Aと事業Bが密接な関係にある場合、事業Aと事業Bは完全に独立した事業です。このとき、サービス A とサービス B で別々のインターフェイスを設計する必要があります。サービス A と B をバインドするインターフェースを 1 つだけ提供するのではなく。
例えば、以下の2つの事業です。
1. 顔の生体検出
2. 顔の照合
この 2 つは密接に関連しており、多くのシナリオでは、顔の信頼性を確認するために最初に生体検出が実行され、次に顔の比較が実行されます。
しかし、「生体検出」と「顔照合」は独立して成立するビジネスです。つまり、「生体検出」または「顔照合」（個人写真をアップロードして本人確認情報を照会するなど）のみが可能です。
インターフェイスとして設計されているだけであれば。
/**
*识别人脸
*/
void identifyFace() {
先活体检测，
再人脸比对
}
上記はこのように設計されていますが、ほとんどのシナリオが適用可能です。ただし、「ライブ検出」と「顔比較」は密接な関係にあるため、「顔比較」を行う場合は、まず「ライブ検出」を行う必要があります。もはや「顔の比較」だけではできません。
より良いアプローチは、2 つのサービスのインターフェイスを個別に設定することです。
/**
*活体检测
*/
void detectFace();
/**
*人脸比对
*/
void matchFace ()
パラメータが意味をなしていることを確認する
より一般的なのは、社内注文番号と社外注文番号です。一部のプロジェクトでは、社内注文番号がルールに従って生成され、クエリ時にこのルールに従うことで、指定されたレコードを迅速に見つけることができます。外部注文番号にもこのような規則がありますが、内部注文番号の規則とは異なるため、内部注文番号と外部注文番号の間のマッピング関係を維持する必要があります。
ただし、社内注文番号または社外注文番号にそのような規則がない場合、実際には注文番号は 1 つだけでなければなりません。
インターフェイスはアトミックである必要があります
インターフェイスは 1 つの関数のみを担当します。ビジネスで 1 つのインターフェイスの設計のみが必要で、複数の関数を呼び出す場合は、アトミック インターフェイスを 2 回カプセル化し、1 つのインターフェイスにパッケージ化する必要があります。
したがって、インターフェイスには 2 種類あり、1 つはビジネス インターフェイス、もう 1 つは単機能インターフェイスです。ビジネスインターフェースは、複数の機能インターフェースを組み合わせて実現できます。
2 つのインターフェイス間に機能的な重複がある場合、それは 2 つのインターフェイスが正しく設計されていないことを意味します。
ビジネスインターフェースのパフォーマンスを考慮する
ビジネスインターフェースが単一の機能インターフェースで構成されている場合、パフォーマンスは低くなります。機能インタフェースの拡張も検討する必要がある。
たとえば、次の状況が考えられます。
機能インターフェイスは 1 つの画像をインポートするものですが、ビジネス インターフェイスは特定のディレクトリに画像をインポートする必要があり、そのディレクトリには 1,000 枚を超える画像が存在する可能性があります。
次のインターフェイスが AIDL インターフェイスであると仮定すると、Android クライアントは 1,000 枚を超える画像をメモリに読み取り、ループ内で次のインターフェイスを 1,000 回以上呼び出す必要があります。さらに、プロセスをまたがって 1,000 枚を超える写真がサーバーに送信され、パフォーマンスが明らかに低すぎます。
/**
* 导入单张图片
*/
void importBitmap(Bitmap bmp);
現時点では、次の機能インターフェイスを拡張する必要があります。
/**
* 批量导入图片
* @param bmpDir 图片所在的目录路径
*/
void batchImportBitmaps(String bmpDir);
この方法では、Android クライアントは 1 回呼び出すだけで済み、Android サーバーで画像を読み取ることができるため、1,000 回のクロスプロセス送信が回避されます。