如何在一个系统中设计权限控制机制(3)

在第一节中，我提出了一个最原始的需求，并定义了几个接口。

在第二节中，我对这个需求进行了一些细化，设计了一个数据结构和一些基本的操作，可以满足一些低层次的需求。在和 babituo 的讨论中，他给我提出了一些更为具体和现实的需求，我想有必要再进一步进行抽象和设计。Babituo提到“如何针对动态创建的一篇文章进行权限的控制”，及其他一些概念对我很有启发。

目标：简单的核心、简单的定制（程序或是配置）、对于常见的情况会有通用的模板。简单的修改可以应付复杂的需求。学习struts。

首先是三个基本的元素：操作者（主）、操作（谓）、资源（宾）。

操作者指的是发出动作的主体，不一定指具体的人，也可以指一组人，或是指系统中的一个模块，它应该是系统唯一的，具有唯一的ID值。

操作指对资源进行的动作，比如说打开、显示等，同样必须具有唯一的ID值。

资源指被操作的对象，可以指单个对象，比如某个菜单项；也可以指某组对象，比如某组菜单。当然这个某组菜单表现出来的也是单一的一个对象。

操作者权限的继续

操作者的父级的权限是能被下级所继续的，比如“小王”是“研发中心”的员工、那么除非明确说明某些权限是小王禁止使用的，研发中心所有的权限，小王都有。这里的继续不是类的继续，而只是业务方面的一个继续或是包含的关系。

新建资源的权限分配，例如：新建文章的操作权限问题

对于新建的文章一般创建者会具有对这篇文章的所有操作权限，所以我设计两个类：新闻类NewsType和新闻类文章类News。新闻类只有一个实例：newsType，它的子女“新闻A NewsA”是对象是“新闻News”的实例。这里子女NewsA并没有从父亲newsType中继续什么功能。“新闻类”具有一接口init()，表明每生成一个实例，就进行一些初始化操作，这里我们可以定义自动将实例的操作权限赋给创建者。当然，这需要定制程序。

新建的操作者的权限分配

这个和新建资源的权限分配类似，对于某操作者类会有一接口init()，描述新建一个实例时所要进行的操作。

操作的组合

例如对于一篇文章的查看、修改、删除操作统称为对一篇文章的治理操作，具有对一篇文章治理操作的权限同时也具有对这篇文章查看、修改、删除的权限。