単一責任の原則SRP

クラスに関して、それが変化する原因は 1 つだけです

オープン・クローズド原則OCP

変更は既存のコードを変更するのではなく、拡張機能によって実装されます。継承などによって新しい実装を追加しないようにしてください。

リスコフ置換原理LSP

親クラスが出現できる限り、主に実装と継承においてサブクラスが出現できます。

依存関係反転の原理DIP

高レベルのモジュールが低レベルのモジュールに依存せず、高レベルのモジュールが詳細ではなく抽象化に依存する、特定の形式の切り離し

インターフェース分離原則ISP

クライアントが依存するインターフェイスをできるだけ少なくします。インターフェイス分割、単一インターフェイス

デメテル原則自民党

最も知られていない原則、オブジェクトは他のオブジェクトについての知識が最も少ない

実用化

ネットワークリクエストフレームワークを設計します。その機能には、ネットワークリクエスト、キャッシュ、戻りデータ分析などが含まれます。

1. 最初の段階:

すべての関数はアクティビティに記述されます

問題点:設計が全くできていない複数箇所で呼び出すと重複コードが多すぎる修正すると全ての箇所の2段目を修正する必要がある

2. 第 2 段階:

リクエストをツールクラス HttpUtils にカプセル化します。

問題: HttpUtils クラスが肥大化しすぎて、実行することが多すぎます。リクエスト、キャッシュなどはすべてこのクラス内で結合されており、返されたデータの分析処理は外部の呼び出し元などによってのみ処理できます。

3. 第 3 段階:

キャッシュ関数を SpHttpCache に抽出します (現在、キャッシュは sp にのみキャッシュされます) (単一責任原則)

HttpCallBackインターフェイスを作成し、リクエストの成功または失敗のコールバックを直接操作し、データ分析や異なる形式で返されたデータの互換性など、返された結果のパブリックイベントの処理をHttpUtilsリクエストに組み込みます。

問題:いくつかの共通ロジックをツールクラスにカプセル化するだけで、スケーラビリティがまったくなく、リクエストコードがすべて 1 つの山に詰め込まれ、呼び出しパラメータが多すぎて、十数個のパラメータをツールクラスに渡す必要がある場合があります。リクエストメソッドやリクエストパラメータなどの構築方法、タイムアウト再接続、タイムアウト期間、Cookieをサポートするかどうかなど。パラメータを拡張する必要がある場合は、さらにコンストラクタを追加する必要があります

4. 第 4 段階:
HttpUtils で、呼び出しをチェーンするようにパラメーターを変更し、呼び出し元が必要とするパラメーターを呼び出し、必要ない場合は呼び出さないようにします。
    public static HttpUtils with(Context context){
        return new HttpUtils(context);
    }

    private HttpUtils(Context context) {
        mHttpRequest = new OKHttpRequest();
        mParams = new HashMap<>();
        this.mContext = context;
    }

    public HttpUtils get(){
        mType = TYPE_GET;
        return this;
    }

    public HttpUtils param(String key,Object value){
        mParams.put(key,value);
        return this;
    }

    public HttpUtils url(String url){
        this.mUrl = url;
        return this;
    }

    public <T> void request(final HttpCallBack<T> callback){
        // 在此做一些异常判断，如url校验等
        mHttpRequest.get(mContext,mUrl,mParams,callback,true);
    }
リクエスト前にパラメータの検証を行う

リクエストを OKHttpRequest クラスにカプセル化します (単一責任原則)
質問:他のネットワークリクエストを使用したい場合は、 HttpUtils の呼び出しのみを変更するか、いつでもネットワークリクエストを切り替えることができます。どのように対処すればよいですか?

5. 第 5 段階:

IHttpRequest インターフェイスを作成し、インターフェイス内で get や post などのメソッドを定義します。

OKHttpRequest リクエストクラスは、IHttpRequest インターフェイスインターフェイスを実装します。

HttpUtils に IHttpRequest パラメーターを追加すると、呼び出し元はチェーン呼び出しを通じて IHttpRequest インターフェイスを実装するサブクラスを渡すことができます。
    private IHttpRequest mHttpRequest;
    ……
    public HttpUtils httpRequest(IHttpRequest httpRequest){
        mHttpRequest = httpRequest;
        return this;
    }

    // 可在application设置默认请求
    public static void initHttpRequest(IHttpRequest httpRequest) {
        mInitHttpRequest = httpRequest;
    }


    public <T> void request(final HttpCallBack<T> callback){
        if(mHttpRequest == null){
            mHttpRequest = mInitHttpRequest;
        }
        // 异常判断
        mHttpRequest.get(mContext,mUrl,mParams,callback,true);
    }
4. 新しいネットワークリクエストを追加する場合は、IHttpRequest を実装するクラスを作成し、httpRequest() メソッドを呼び出して、呼び出し時に必要なネットワークリクエストを設定するだけです。

開始と終了の原則:新しいネットワークリクエストを追加する必要がある場合、HttpUtils のコードを変更する必要はありません。追加する必要があるのは新しいクラスだけです。拡張にはオープンで、変更にはクローズされます。

Liskov 置換原則:親クラス IHttpRequest が出現する場合、サブクラス OKHttpRequest が出現する可能性があります。HttpUtils.initHttpRequest(new OKHttpRequest());

依存関係逆転の原則:高レベルの HttpUtil は、低レベルの詳細 (OKHttpRequest) には依存せず、低レベルの抽象化 (IHttpRequest) に依存します。

ディミッターの原則: MainActivity では、HttpUtils を使用してネットワークリクエストを作成します。その実装方法は関係ありません。必要なパラメータを渡すだけで、最終結果を取得することができます。残りは気にしないでください。

5. キャッシュクラス、メモリキャッシュ、ディスクキャッシュ（データベース、ハードディスク）についても同様です。

頻繁に使用されるインターフェイスはメモリとディスクにキャッシュでき、使用頻度の低いインターフェイスはディスクに直接キャッシュできます。

Android デザインパターンの 6 つの基本原則

単一責任の原則SRP

オープン・クローズド原則OCP

リスコフ置換原理LSP

依存関係反転の原理DIP

インターフェース分離原則ISP

デメテル原則自民党

実用化

1. 最初の段階:

2. 第 2 段階:

3. 第 3 段階:

4. 第 4 段階:

5. 第 5 段階:

おすすめ