android:关于离线在线策略引发的思考以及类似业务的封装

离线在线策略，简单解释一下就是一个业务，在有网情况下，能实现，在无网情况下，也能实现。
首先能想到的就是用户主动同步数据，比如用户主动向数据库同步数据，然后本地数据库相当于一份网上数据库的备份，然后切换到无网环境，用户操作完业务，再到有网环境，主动同步一下，这样就能实现离线的操作，回到网上数据库。
这样的具体实现我们先不讨论，后期做，咱先做怎么让一个业务能有两种实现，然后根据实际情况，让系统自己决定走哪个实现。
相当于一个接口，两种实现，根据需求不同，选择需要的实现。

这样的话，写一个接口类，然后在情况选择的地方，做个判断，根据情况不同，让接口对象等于需要的接口实现对象，
就能实现同一个接口，不同情况，有不同效果了。

仅仅是这样还是在造*，就没有写这个txt的效果了，所以我打算更深入一点

先把造的*放上(就是简单的一个接口多个实现用if决定用哪个实现)，放完之后再写更深入的东西：
接口类：

/**
 * <p>
 * 一个接口
 * </p>
 *
 * @author mythS
 * @since 2020/5/14 15:35
 */
public interface JieKou {
    /**
     * 用于测试两种状态的下的接口
     */
    int test();
}

第一种情况的实现类：

/**
 * <p>
 * 接口在1情况下的实现
 * </p>
 *
 * @author mythS
 * @since 2020/5/14 15:38
 */
public class JKShiXian1 implements JieKou {
    @Override
    public int test() {
        return 1;
    }
}

第二种情况的实现类：

/**
 * <p>
 * 接口在2情况下的实现
 * </p>
 *
 * @author mythS
 * @since 2020/5/14 15:38
 */
public class JKShiXian2 implements JieKou {
    @Override
    public int test() {
        return 2;
    }
}

判断以及选择不同的接口实现：

/**
 * <p>
 * 类似主入口吧
 * </p>
 *
 * @author mythS
 * @since 2020/5/14 15:39
 */
public class Test {

    JieKou jieKou;

    public void test(int qingkuang) {
        if (qingkuang == 1) {
            //走1接口
            jieKou = new JKShiXian1();
        }
        if (qingkuang == 2) {
            //走2接口
            jieKou = new JKShiXian2();
        }
        int n = jieKou.test();
        Log.i("提示", "" + n);
    }

}

使用举例：

Test test = new Test();

如果要第二种实现，就这样：

test.test(2);

如果要第一种实现，就这样：

test.test(1);

--------------------------------重点分割线----------------------------------------

重头戏，不造*。
既然是更深入，肯定是在原先基础上深入。
首先，情况选择的地方，还是太臃肿，我甚至只想传个“情况”，自然而然就能得到自己需要的实现。
那么OK，做一个能接收“情况”参数的工具类，在这个类中进行判断，并选择合适的实现。
但是仅仅想到这个还不够，我们要让我们的类更加适应多种类似的业务。

首先我们需要明确要做出什么效果：
1、用户继承我的“策略封装类”，需要复写一个自己的“什么情况，用什么策略”的方法（拥有了更广泛的适用性）
2、开放一个api，能够让用户传入“实现类”获取其实例（用户可以在需要的时候，直接取需要的实例）
3、接口的调用不再是用接口本身的名字，而是用自己继承“策略封装类”后子类的实例调用（让程序和接口解耦）

首先，上面“造*”写的一个接口以及两个实现类，这里直接拿来用（程序员都“懒”）

下面直接上代码，代码后跟上解释：
策略的封装类（核心）：

/**
 * <p>
 * 策略的封装类
 * </p>
 *
 * @author mythS
 * @since 2020/5/15 13:19
 */
abstract class BaseStrategy {

    /**
     * 策略的逻辑
     * 继承这个抽象类，需要个性化实现这个方法
     *
     * @param n   不同情况的标识，比如0是在线1是离线
     * @param <E> 返回接口的实例（复写后一定要换成自己接口的全限定性名）
     *
     * @return 所需求情况下的实例
     */
    public abstract <E> E cur(int n);

    /**
     * 获得实现类实例
     *
     * @param eClass 实现类全限定性名
     */
    protected static <E> E getImpl(Class<?> eClass) {
        String s = getClassFullName(eClass);
        return (E) getImplCur(s);
    }

    /**
     * 全限定名字符串处理
     */
    private static String getClassFullName(Class<?> eClass) {
        String s = eClass.toString();
        if (s.split(" ").length > 1) {
            s = s.split(" ")[1];
        }
        return s;
    }

    /**
     * 利用反射根据类名获得其实例
     */
    private static Object getImplCur(String s) {
        Object o = null;
        try {
            o = Class.forName(s).newInstance();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        return o;
    }
}

这个类就是这次思考的核心。总体来说这个类的涉及思路就是，通过传进来一个“实现类”的全限定性名，
然后利用反射生成其实例（getImplCur方法）。实例赋值给开放api方法getImpl。
定义一个抽象方法cur，参数就是不同情况的标识，用户自己拟定，比如在线是0，离线是1，根据自己的业务拟定。
这样用户继承这个“父类”的时候，重写这个，根据标识，利用开放api方法getImpl，获得需要的“实现类”就能完成我们的预想了。

下面举例说明怎么使用：
第一步，上代码：

/**
 * <p>
 * 举例使用策略
 * </p>
 *
 * @author mythS
 * @since 2020/5/15 15:08
 */
public class TestStrategy extends BaseStrategy {
    @Override
    public JieKou cur(int n) {
        //1也就是在线时，需要JKShiXian1的实现
        if (n == 1) {
            return getImpl(JKShiXian1.class);
        } else {
            return getImpl(JKShiXian2.class);
        }
    }

}

就是简单的创建一个子类，继承BaseStrategy，然后根据自己的业务复写cur方法，
我这里是假设在线时需要JKShiXian1的实现，离线时需要JKShiXian2的实现。n为1代表在线。

在具体需要使用的地方，实例化子类TestStrategy为u，然后直接u.cur(2).test()就能获得JKShiXian2的实现效果。
代码：

TestStrategy u = new TestStrategy();
Log.i("提示", "" + u.cur(1).test());

补充：
如果觉得上面两行太麻烦，还需要new对象，可以在TestStrategy写一个静态方法cur1，
然后内容和复写cur方法时里面的内容一样，然后注掉cur内容，返回个null（就是不用这个了）
然后在需要调用的地方直接TestStrategy.cur1即可。
这也是上面说的”需要实现的效果2“的开发api的好处，使用者比较*。

本文地址：https://blog.csdn.net/sadkhkuhkjasga/article/details/107598477