权限抽象
背景
小时光开发到现在，量级也算比较大了，回想这一年，做了很多搬砖的事情，比方说更改权限、添加广告位、增加记录类型等，每一次更改都倒腾一次。所以想能否将这些易变的事情抽象出来，对修改封闭，对扩展开放，客户端尽量能不发版实现需求。于是，就有了一系列的思考。这篇主要是关于如何将权限抽象出来，做到以后更改权限方面的需求，尽量能做到客户端不发版直接搞定，Server端不改代码或者少改代码搞定。
依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
| 能力/角色 | 创建者 | 管理员 | 亲友 | 粉丝 | ...... |
|---|---|---|---|---|---|
| 看记录 | Y | Y | Y | Y | |
| 删除记录 | Y | N | N | N | |
| 小家改名 | Y | N | N | N | |
| 邀请成员 | Y | Y | Y | N | |
| 删除成员 | Y | Y | N | N | |
| ...... |
- 横向（角色）延伸
- 纵向（能力）延伸
客户端如何不发版，server端如何能够不改或者少改代码？
客户端
A. 增加一种角色 / 已有角色已有能力改变 （横向）
举例： 增加一种叫同事的角色
将目前的“通过角色确定权限”的方式，改为统一通过server端询问是否拥有能力。基本不需要知道角色这个概念。
拿“删除记录”按钮是否应该显示举例：
B. 增加一种能力 （纵向）
(1) 能力是已有的功能，但是一开始没有加权限判断
以“查看家庭成员列表”为例，原来有这个功能，任何人都可以进入这个页面，没有考虑权限的问题。
点击“小家列表”后，将走小家列表路由（5），底层捕捉到这个路由URL，由于是需要判断权限的路由，通过Server判断权限，如果没有权限，则返回上一页或者显示无权限页面。（2，3）
(2) 能力是没开发的功能（比如增加一个备注昵称的功能）
借助页面元素抽象化，以及RN，通过页面元素抽象可以动态增加一个入口，然后通过将页面的重要参数（4）传给RN，完成操作后RN可以调用本地页面方法，比如刷新页面（1）。
Server
设计到3张配置表的维护
- 角色表
- 能力表
- 角色/能力配置表
代码类似：
// 角色为“同事”能否查看“公开记录”
bool checkAccessWithRoleIDAndService:(4,“get_public_data”); // Y无论“增加能力”还是“增加角色”都是维护着三张表。具体流程如下（以“能否查看评论”为例）：
