离线在线策略，简单解释一下就是一个业务，在有网情况下，能实现，在无网情况下，也能实现。
首先能想到的就是用户主动同步数据，比如用户主动向数据库同步数据，然后本地数据库相当于一份网上数据库的备份，然后切换到无网环境，用户操作完业务，再到有网环境，主动同步一下，这样就能实现离线的操作，回到网上数据库。
这样的具体实现我们先不讨论，后期做，咱先做怎么让一个业务能有两种实现，然后根据实际情况，让系统自己决定走哪个实现。
相当于一个接口，两种实现，根据需求不同，选择需要的实现。
这样的话，写一个接口类，然后在情况选择的地方，做个判断，根据情况不同，让接口对象等于需要的接口实现对象，
就能实现同一个接口，不同情况，有不同效果了。
仅仅是这样还是在造轮子，就没有写这个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
如对本文有疑问， 点击进行留言回复！！
android RecyclerView checkbox复用解决
Android Q Input (1) -- InputManagerService启动
android -- ndk (stack corruption detected)
网友评论