Six principes de base des modèles de conception Android

Principe de responsabilité unique SRP

Par rapport à une classe, il n'y a qu'une seule cause pour qu'elle change

Ouvert Fermé Principe OCP

Les changements sont implémentés au moyen d'extensions, plutôt qu'en modifiant les codes existants. Essayez de ne pas ajouter de nouvelles implémentations par héritage, etc.

Principe de substitution de Liskov LSP

Tant que la classe mère peut apparaître, la sous-classe peut apparaître, principalement dans l'implémentation et l'héritage

Principe d'inversion de dépendance DIP

Une forme spécifique de découplage dans laquelle les modules de haut niveau ne dépendent pas des modules de bas niveau, et les modules de haut niveau ne dépendent pas des détails mais des abstractions

Principe de séparation des interfaces FAI

Laissez le client dépendre d'aussi peu d'interfaces que possible. Interface divisée, interface unique

Principe Demeter LDP

Le principe du moins connu, un objet a le moins de connaissances sur les autres objets

Application pratique

Concevez un cadre de requête réseau, les fonctions incluent : requête réseau, cache, analyse des données de retour, etc.

1. La première étape :

        Toutes les fonctions sont écrites dans Activity

  Problème : Il n'y a aucune conception. Il y a trop de codes en double lors d'appels à plusieurs endroits. Si vous le modifiez, vous devez modifier la deuxième étape à tous les endroits.

2. La deuxième étape :

        Encapsulez la requête dans la classe d'outils HttpUtils

  Problème : la classe HttpUtils est trop gonflée et fait trop de choses. Les requêtes, les caches, etc. sont tous couplés dans cette classe, et le traitement d'analyse des données renvoyées ne peut être traité que par des appelants externes, etc.

3. La troisième étape :

1. Extrayez la fonction de cache dans SpHttpCache (actuellement, le cache n'est mis en cache que sur sp) ( principe de responsabilité unique )
2. Créer l'interface HttpCallBack, opérer directement le rappel du succès ou de l'échec de la requête et placer le traitement de l'événement public de résultat renvoyé dans la requête HttpUtils, comme l'analyse des données et la compatibilité des données renvoyées dans différents formats

  Problème : encapsulez simplement une logique commune dans une classe d'outils, il n'y a aucune évolutivité, le code de la requête est entassé dans une seule pile, il y a trop de paramètres d'appel et plus d'une douzaine de paramètres peuvent devoir être transmis au méthode de construction, telle que la méthode de requête et les paramètres de requête, la reconnexion du délai d'expiration, le délai d'expiration, la prise en charge des cookies, etc. Si vous avez besoin d'étendre les paramètres, vous devez ajouter plus de constructeurs

4. La quatrième étape :   

1. Dans HttpUtils, modifiez les paramètres pour chaîner les appels, appelez les paramètres dont l'appelant a besoin et n'appelez pas s'il n'en a pas besoin

2.     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);
       }

3. Effectuez une vérification des paramètres avant de demander
4. Encapsuler la requête dans la classe OKHttpRequest ( principe de responsabilité unique )

  Question : Si vous souhaitez utiliser d'autres requêtes réseau, vous ne pouvez modifier que l'appel de HttpUtils, ou vous pouvez changer de requête réseau à tout moment, comment y faire face

5. La cinquième étape :   

1. Créez une interface IHttpRequest et définissez des méthodes telles que get et post dans l'interface
2. La classe de requête OKHttpRequest implémente l'interface d'interface IHttpRequest
3. Ajoutez un paramètre IHttpRequest dans HttpUtils et l'appelant peut transmettre la sous-classe qui implémente l'interface IHttpRequest via des appels en chaîne

    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. Si vous souhaitez ajouter une nouvelle requête réseau, il vous suffit de créer une classe qui implémente IHttpRequest et d'appeler la méthode httpRequest() pour définir la requête réseau requise lors de l'appel.

        Principe d'ouverture et de fermeture : lorsque de nouvelles requêtes réseau doivent être ajoutées, il n'est pas nécessaire de modifier le code de HttpUtils, seules de nouvelles classes doivent être ajoutées, qui sont ouvertes pour extension et fermées pour modification.

         Principe de substitution de Liskov : là où la classe parente IHttpRequest apparaît, la sous-classe OKHttpRequest peut apparaître, HttpUtils.initHttpRequest(new OKHttpRequest());

         Principe d'inversion de dépendance : les HttpUtils de haut niveau ne dépendent pas des détails de bas niveau (OKHttpRequest), mais des abstractions de bas niveau (IHttpRequest)

        Principe Dimiter : dans MainActivity, utilisez HttpUtils pour effectuer des requêtes réseau, quelle que soit la manière dont il y est implémenté, ne connaissez que les paramètres à transmettre, récupérez le résultat final et ne vous souciez pas des autres

     5. Il en va de même pour la classe cache, le cache mémoire, le cache disque (base de données, disque dur)

        Les interfaces fréquemment utilisées peuvent être mises en cache dans la mémoire et le disque, et les interfaces peu utilisées peuvent être mises en cache directement dans le disque