操作系统理论的探索(之一)
2007-09-29 12:30:22 来源:WEB开发网核心提示: 参与协议定制的非产品制作方的用户和操作协议的关系显然,这里指的操作协议是多方定制的操作协议,操作系统理论的探索(之一)(7),这样的用户是该产品的上游或下游产品链上的产品制造者,他们参与了操作协议制定,进行理解,但理解范围总是在自己需要的那部分范围中,而这样的操作协议是两者产品的组合操作协
参与协议定制的非产品制作方的用户和操作协议的关系
显然,这里指的操作协议是多方定制的操作协议,这样的用户是该产品的上游或下游产品链上的产品制造者,他们参与了操作协议制定,而这样的操作协议是两者产品的组合操作协议,因此他们对操作协议有深入的了解,拿到产品后目的是为了与自己手中的其他相关产品进行组合,这种组合是按照共同定制的操作协议来完成。
因此这样的用户对操作协议(产品公开的部分)的理解是完全的,对产品的使用是完全按照操作协议(产品公开的部分)进行的,如图:
这样的操作协议的性能高低取决于多方定制中达成的一致性的程度,即多方的磨合度。
而这种用户在面对单方定制的操作协议时和第三种用户的待遇相同。
一般用户和操作协议的关系
对于一般用户来讲,因为没有参与制造或者协议的定制,在面对单方定制的操作协议和多方定制的操作协议时,情况是等同的,他们对产品的了解是建立在对产品操作协议的理解程度。
即一般用户得到产品和操作协议时,首先做的事是理解操作协议,然后使用产品,对于没有操作协议说明的产品,用户通过产品的外在表现来理解其操作,从实践角度勾勒出操作协议的原貌。
这种理解在多数情况下是单向的理解(社会分工导致的结果),即使用产品的一方没有机会和开发产品者进行深入交流,使得产品使用者彻底理解操作协议的内容。
作为产品制作者,总是把产品的操作协议详细描述,而描述方式多数情况下是按自己的行业思考模式进行的,因为产品就是这种思考模式的设计产物而使用者是从自己的思考模式入手进行的分析,得出一个需要外部产品功能的需求,进而找到了该类产品的操作协议,进行理解,但理解范围总是在自己需要的那部分范围中,即是产品操作协议的一个子集。
- ››探索 ConcurrentHashMap 高并发性的实现机制
- ››操作系统资源不足两种方案解决办法
- ››探索Asp.net mvc 的文件上传(由浅入深)
- ››探索博客发展之路:给博客一个明确的定位
- ››探索 Eclipse JDT 中的重构功能
- ››探索 Eclipse 的 Ajax Toolkit Framework
- ››探索 Eclipse V3.1 的新特性:更高的可用性、更广...
- ››操作系统拾遗之进程和线程
- ››探索 Flex 和 CSS 的强大功能
- ››探索 Pexpect,第 1 部分:剖析 Pexpect
- ››探索 Pexpect,第 2 部分:Pexpect 的实例分析
- ››操作系统还原:你需要明白的几件事
更多精彩
赞助商链接