基于分布式对象的网游程序结构设计(4)-SRP分布式对象的概念
作为游戏中的一个角色。在服务器端和客户端同时存在，服务器端负责角色对象的逻辑，以及各种属性的更新；客户端负责角色对象的显示，与玩家进行交互。这应该是一种非常典型的分布式对象模式。但是目前的分布式对象技术，能够支持这种模式吗；答案是不支持，没有使用Web Service或者Cobra/DCom开发的游戏。因此可以说目前的分布式对象的 概念，还存在不完善的地方。本节针对此问题进行讨论，并提出SRP分布式对象的概念。
目前对于分布式对象的概念，一般指RMI、COBRA、DCOM等分布式组件技术。但是我们认为对象应该是具有属性的，不应该只有方法；在面向对象编程语言中的对象概念更加贴切。而目前的组件技术，都是只提供了一个抽象的接口，即便是Web Service，也只供了远程调用的方法（可以看作是一个抽象的接口），并没有提及属性，而且也不支持定义属性。在分布式应用中，对象的属性重要吗？目前的组件技术和Web Service技术，都没有定义属性，不是发展的很好，也能够方便的应用于各种场合下吗？
回答这个问题，这里简单的给出一个例子：对象在某些状态下（例如：忙），某些接口不能够调用（例如：查询），调用会返回错误。按照目前组件技术的描述方法，如下：
Interface objectclass{
char *Query( in int arg, out int result);
};
对于该组件的使用者，如何调用呢，反复调用Query函数，直到正确的结果吗？这个例子非常简单，但是使用目前的分布式组件技术，很难实现。对象的属性分布到客户端（调用者），有利于客户端根据对象的状态，更加灵活地进行服务调用，为客户提供更好的服务。仅仅是对象的属性分布到客户端就够了吗？
回想前面对于Web技术的发展过程中，javascript为什么引入，并得到迅速发展。在客户端和服务器端进行交互时，如果客户端能够进行一些预先的处理，也能够提供更好的服务。比如简单类似输入参数的校验问题，如果在客户端能够进行，则不再需要再发送到服务器，并等待几秒甚至几十秒之后，再得到错误的反馈。这需要把部分对象的脚本（甚至代码）也需要部署到客户端，
Web Service和组件模型提出了一种新的编程模型，这也是出现和发展起来的原因。但是快速发展不能够说明这些技术本身不存在问题，对于相对复杂的Web服务，细粒度的组建服务，这些技术还不是很成熟，或者说，不能够进行处理。本文提出的SRP分布式对象模型，解决了这些问题。
这里提出的分布式对象的概念如下：
对象具有属性，方法和执行脚本（代码）。对象在服务器端和客户端同时存在，并且客户端对象有与服务器端相同的属性。客户端对象和服务器端对象通过唯一标识（一般使用UUID）建立一一对应关系。
对象的属性，脚本（代码）如何分布到客户端，这就需要分布式对象管理系统。
针对上述的例子，如下：
Interface objectclass{
Int BusyFlag；
char *Query( in int arg, out int result);
};
这样客户端首先判断BusyFlag是否设置，如果设置，则不进行调用，如果没有设置，则可以调用。
采用对象的概念，分布式对象管理系统可以为上层的应用，提供一个统一的接口，即分布式对象管理接口。通过该接口，可以获取对象，对象的属性，调用对象的方法，并接收对象的异步事件。
对于前面Web技术和组件技术存在的问题，采用分布式对象的技术，则可以如下处理：
1． 数据和资源文件反复下载
每种数据或者资源，都可以定义为一个对象，对象定义属性，说明数据或者资源的版本；如果数据发生变化，则对象对应的版本属性发生变化，客户端判断属性发生变化之后，再重新下载。如果相同，则不需要下载，直接使用本地缓存的数据即可。
2． 不方便维护客户端状态维护
分布式对象管理，支持常连接模式，以方便支持需要维护状态的应用。
3． 服务器端不能够主动发起数据的传输。
分布式对象管理，支持常连接模式，服务器可以通过该连接，修改对象的属性，与客户端进行通信。
4． 编码简单，通信传输的开销大
分布式对象管理，支持使用自定义通信，在某些追求效率的应用场合，
5． 细粒度模型
通过分布式对象管理，对象分布到客户端，客户端直接使用对象的属性或者调用对象的方法。不再需要针对每个对象，执行远程创建的过程，因此能够支持成千上午个对象。
这种分布式对象模型，能够用于游戏中吗，答案是可以。对象属性同时在服务器和客户端存在，服务器端更新对象属性之后，由分布式对象管理将属性同步到客户端，客户端刷新显示。客户端可以调用服务器端的对象的方法，服务器进行逻辑控制，修改对象的属性。