ARPG客户端中场景对象体系设计

一、场景对象体系

二、场景对象生命周期管理

场景对象的生命周期,不适合采用原始的c++管理方式, 即由使用者自己负责删除。而应该采用引用计数方式, 自动负责删除。

采用引用计数方式, 目前用法比较广的分两类:

1、智能指针, 如boost::shared_ptr, 这种方式原理是基于c++对象的生命周期和析构函数来实现的, 而且引用计数是由智能指针对象保存的。在这种方式下, 对象的传递和引用都是使用智能指针对象, 例如:

 class A;
 typedef boost::shared_ptr<A> TAPtr;

 //B需要保留对A的引用
 class B
 {
 public:
     void AccessA(TAPtr a)
     {
         m_a = a;

         //省略
     };     

 private:
     TAPtr m_a;
 };    

 //C不需要保留对A的引用, 而仅仅是在某个接口中要访问A
 class C
 {
 public:
     void AccessA(TAPtr a)
     {
         //省略, 访问a
     };
}; 

这种方式的优点:

使用者没有任何负担。

缺点:

[1] 效率低。

[2] 不方便暴露对象给lua使用。

2、cocos2d中的Ref方式, 即由对象自身来保存当前的引用数, 并且由对象的使用者自己来负责增加引用数retain和减少引用数release。 在这种方式下, 对象的传递和引用都是使用对象指针来实现, 例如:

 class A: public Ref;

 //B需要保留对A的引用
 class B
 {
 public:
    ~B()
    {
        if(m_a)
        {
            m_a.release();
            m_a = NULL;
        }
    }

     void AccessA(A *a)
     {
         m_a = a;
         m_a.retain();

         //省略
     };     

 private:
     A *m_a;
 };    

 //C不需要保留对A的引用, 而仅仅是在某个接口中要访问A
 class C
 {
 public:
     void AccessA(A *a)
     {
         //省略, 访问a
     };
}; 

这种方式的优点是:

[1] 效率高, 无论是传递、访问还是对于引用计数的操作(由使用者本身决定是否要调用retain和release)。

[2] 方便把对象暴露给Lua使用。

缺点是:

增 加了使用者自身的负担, 很容易造成内存泄露, 这正是因为由使用者本身决定是否要调用retain和release引起的。基于相同的原因, 如果要用容器(比如list, vector等)来保存对象时, 标准库中的容器没办法直接使用, 而必须封装, 或者在插入和删除元素是, 手动调用元素的retain和release.

时间: 2024-10-16 01:45:30

ARPG客户端中场景对象体系设计的相关文章

Python对象体系揭秘

Guido用C语言创造了Python,在Python的世界中一切皆为对象. 一.C视角中的Python对象 让我们一起追溯到源头,Python由C语言实现,且向外提供了C的API http://docs.python.org/c-api/index.html . 我们思考问题的时候,可能对于对象这种东西很容易理解,而计算机能理解的只有0,1序列这样的字节序列,从根本上讲,我们所说的计算机语言中的对象只是在内存中的一块内存空间里的0,1序列而已,这些连续或者非连续的内存空间在更高层次上可以看作是一

连载15:软件体系设计新方向:数学抽象、设计模式、系统架构与方案设计(简化版)(袁晓河著)

从置换到面向对象 对象化的划分,需要通过逻辑的分解进行,然而分解不过是我们有限的思维能力下的一种使用方法而已,我们在进行逻辑分解的过程中过多夸张了其独立性,是从某一个角度和一个方面来分解,然而对于无限的客观对象,我们只能够近似的逼近,客观对象永远是彼岸无法企及. 客观对象具有无穷多的参照方面,因为其本身的无限,是无法通过有限的分解将其分离.所以分解完成以后,组合这些分解完成的对象是无法表示未分解客观对象的整体特征,这些整体特征将按照其他的原理在运作,所以虽然肉体都是由大大的细胞组成,但是这些细胞

深入分析面向对象中的对象概念(转)

OOP:面向对象编程,一提到面向对象,大家可能就想到类,接口.一说特性,大家可能张口就来:继承.封装.多态,那么到底什么样的对象(类)才是真正意义上的对象呢?特别是现在流行的DDD领域驱动设计思想,讲究职责划分,那么如何定义一个对象(类)它应该具有的一些特性.行为方法及承担责任成为关键. 一个看似简单的问题,其实也是耐人思索,之前也在网上看到一些人关于讨论类的设计问题,认为设计类时不应该考虑数据库,我觉得这只是实现真正的面向对象设计的基础,也是前提条件,大多数程序员之前都是受面向过程编程思想的影

Discuz!NT中的Redis架构设计

在之前的Discuz!NT缓存的架构方案中,曾说过Discuz!NT采用了两级缓存方式,即本地缓存+memcached方式.在近半年多的实际运行环境下,该方案经受住了检验.现在为了提供多样式的解决方案,我在企业版里引入了Redis这个目前炙手可热的缓存架构产品,即将memcached与Redis作为可选插件方式来提供了最终用户,尽管目前测试的结果两者的差异不是很大(毫秒级),但我想多一种选择对用户来说也是好的. 闲话不多说了,开始今天的正文吧.         熟悉我们产品的开发者都知道,我们的

IM系统中聊天记录模块的设计与实现

看到很多开发IM系统的朋友都想实现聊天记录存储和查询这一不可或缺的功能,这里我就把自己前段时间为傲瑞通(OrayTalk)开发聊天记录模块的经验分享出来,供需要的朋友参考下. 一.总体设计 1.存储位置 从一开始我们就打算在服务端和客户端本地同时存储聊天记录,而且,在客户端查看聊天记录时,可以选择是从本地加载.还是从服务器加载.这样做的好处有两个: (1)从本地加载聊天记录速度非常快. (2)当更换了登录的机器,在任何地方任何时刻都可以从服务器加载完整的聊天记录,记录永远不会丢失. 2.存储方案

.NET数据库连接中的对象

 在学习VB.NET视频时,其中有几个单元讲到了.NET的数据库设计与连接.对于数据库的连接,其实我们并不陌生,原来在做红皮书和机房收费系统的时候,我们都有接触过,可是,在我的印象中,这些关于数据库连接的知识很是模糊.对于数据库连接对象更是一知半解. 回过头来,翻了一遍红皮书中的几个实例,里面讲到了利用ADO控件来连接数据库,它涉及到的数据库连接对象有7个(connection,command ,recordset,Field,Property,parameter,error) 那么对于如今

atitit.插件体系设计总结o73.doc

1. 两大类型:微内核(级联树形结构)与巨内核(管理容器,并联结构). 1 2. 通用插件接口 1 3. 插件的绑定and 初始化 2 4. 微内核插件平台设计 2 5. 参考 2 1. 两大类型:微内核(级联树形结构)与巨内核(管理容器,并联结构). 插件系统主要有两大类型:微内核(级联树形结构)与巨内核(管理容器,并联结构). 其中,微内核的主要特点是拥有父插件.子插件,而界面呈现是由扩 展点的父插件来决定,插件交互也是通过国展店实现的.此外,插件之间的赖关系由配置文件制定,其延迟加载也是由

深入分析面向对象中的对象概念

OOP:面向对象编程,一提到面向对象,大家可能就想到类,接口.一说特性,大家可能张口就来:继承.封装.多态,那么到底什么样的对象(类)才是真正意义上的对象呢?特别是现在流行的DDD领域驱动设计思想,讲究职责划分,那么如何定义一个对象(类)它应该具有的一些特性.行为方法及承担责任成为关键. 一个看似简单的问题,其实也是耐人思索,之前也在网上看到一些人关于讨论类的设计问题,认为设计类时不应该考虑数据库,我觉得这只是实现真正的面向对象设计的基础,也是前提条件,大多数程序员之前都是受面向过程编程思想的影

演进架构中的领域驱动设计

from:http://www.infoq.com/cn/articles/ddd-evolving-architecture   领域驱动设计能非常容易地应用于稳定领域,其中的关键活动适合开发人员对用户脑海中的内容进行记录和建模.但在领域本身不断变化和发展的情况下,领域驱动 设计变得更具有挑战性.这在敏捷项目中很普遍,在业务本身试图演进的时候也会发生.本文分析了在反思.重建guardian.co.uk这一为期两年的计 划背景下我们是如何利用DDD的.我们展示了如何确保在软件架构中反映最终用户演