在使用unity3d之前,我已经知道组件设计的概念,我们某个项目实际上也是基于组件的,虽然底层引擎只是设计了一个最简单的组件框架,遗憾的是其他部分,并没有按照多少组件的意思来组织代码.这个组件失败的地方在于,没有提供一个很好的组件之间通信的方法.我们的组件系统使用一个interface类作为组件提供内在功能的手段.好处在于,使用该interface类你无需包含特定组件的细节(不用包含组件头文件).坏处是,该interface类本身很庞大,因为他使用仿函数(boost function)作为与组件通信的方式,对于组件的每一个需要暴露的功能,都需要在interface中添加一个functor变量.使用仿函数的另外一个困扰是当需要将interface导入脚本时遇到困难,我相信研究一番是可以找到办法的(最后的底线是用普通函数或类函数再把仿函数封装一番). 面向对象的设计模式那一套,大部分说穿了都可以转化为某种形式的map,就是说它们其实是在表现一种映射关系,我之前在想为什么?我知道这种映射关系在oo设计中是不可避免的,但没有一个简单优美的解释让我释怀.直到看到Go语言设计者的关于Go的旧金山大会演讲,里面提到--"我已故的朋友Alain Fournier曾告诉我，他认为学术工作最基本的要求就是分工。你知道吗？类型层次也只是一种分类法。"--是的,面向对象就是一种分类学,所以映射关系必然会被体现出来,所以map几乎就是面向对象设计模式所必须的工具.个人觉得,使用map实现分类关系没什么不好意思的,可是有时候非要用一层套一层的代码来隐藏map,简直就是居心叵测,本来没什么意思的在我看来也变成有意思的了,你是在掩饰自己不过是使用了map的事实吗?不过,映射关系在程序中确实重要,与使用不使用面向对象设计无关.因为程序就是对逻辑关系的抽象,逻辑关系通常又受限于现实的实体关系,而人类归纳的直觉之一既是映射.回到我们的项目,既然组件内部使用了map来查找特定的interface类,那么,何必在意再使用map来查询内部的方法?我觉得,使用类&#;getCompoent("compoennt_name")->invoke("function_name")就可以了.然后减少那些枝枝叶叶的模板,设计模式方法,你就实现2个map查询就完了,不需要更多.Go语言实际上只内建了array(数组), map(映射)两种数据结构.array是一种内聚非常高的数据结构,map恰恰相反,是一种非常松散的数据结构.除了是一些算法的必需品外,map常被用在一些需要解除耦合的地方.设计模式的一大目标就是解耦合,map 的使用就是必然的了.但常常一些代码中,为了解耦合,引入了过多的封装类,这实际上与初衷背道而驰.我要学习的是,让数据尽可能自然的表现它所代表的事物,然后呆在它显而易见该呆的地方. 以上是毫无头绪的关于设计模式中map关系的吐槽.无视之. 组件设计,打破了较为僵硬的继承关系,而使用映射关系表示实体关系.以前在<备忘:c#接口与抽象类>中说过: --"而抽象类或者类的概念,是程序里具体的代码组织关系的一种体现.关注的是同质实体之间的关系." --"抽象类或者说类的概念,是在某种语言环境下,对代码间的复用和对代码间的约束这2个耦合关系的一种实现手段." 继承体系遇到的困难之一就是,世间万物的关系并不是那么单纯,存在很多灰色地带.毕竟它关注的更多是同质实体间的关系.而对于3d游戏中,一个实体,可能包含脚本,网&#;,物理,声音,消息对象等等.不管你用单继承,或是用多继承,都会遇到继承体系固有的问题,比如臃肿的接口,比如重载问题,比如多继承下的菱形问题等等,这还只是一些语义问题,睁只&#;闭只&#;也许也就过去了,更难受的是对于一些实际操作,类&#;序列化到磁盘(存档),反序列化(读档),继承体系面临的复杂性很高,例如多继承下的反序列化工作,看一&#;都要瞎掉. 可能有人会说,组件不过就是设计模式中的组合模式.一个组件不过是一个类成员变量而已,因此还是类体系的传统方法.组件设计某种程度上确实是一种组合模式.不同的是,传统的类体系组合模式体现的是一种固有,内定的内聚关系.而组件模式体现的是松散的,动态的关系.比如设计一个person类,组合模式可以定义hand,foot,head,brain这4个成员变量组合为一个person,但它们缺一不可.组件系统确是person可以动态的添加hand,foot,head,brain这4个组件,也就是说完全可以有缺少brain的person出现.从这个意义上说,person已经不是一个类,而是一个集合. 可以说,组件模式更接近于数学描述,而继承模式,更接近于分类学阐释. 组件方法在面向对象语言中,也并不是完全抛开了继承.对于基础组件,它本身可能就是一套内聚非常高的类体系,因为它不需要动态修改,或它的专业性非常高(物理),或非常麻烦(IO),一旦完成,即作为组件只管提供功能就足够了.组件方法本身的概念简单明了,并没有什么神秘的.组件设计的难点,同样牵涉到基础构件的实现. 组件设计最基础的是需要一套映射机制,体现在算法上是map,这个数据结构各个语言都有现成实现,无需困扰.而体现在语法层面的,则是需要一套反射机制.类&#;c#及大批动态语言,都原生的提供了这个机制.而在c&#;&#;中,必须自己实现.通常,都需要实现一个完善的rtti系统.回到我们的某个项目,就是因为引擎提供了组件这个概念,也给出了查询组件的实现,但却没有一个rtti系统来实现反射机制,从而实现映射关系,导致不伦不类,致使后边的人一直不得要领.另外,我们使用的3d引擎是一款开源引擎,其他常用库也基本是开源里拿过来的.除了逻辑层,都是外援.因此在实现构件中,你会发现材料并不是按照你组件的思路来写的,这时候会遇上很痛苦的事.比如你希望有animaition组件,该组件应该跟entity组件划分立场清楚,但是在你使用的3d引擎中,animation中,skeleton与entity牢牢的结合在一起的,如果在entity组件里包含skeleton组件,就会有多个entity包含相同的skeleton问题,skeleton只需要一份就够了.这是否意味着,你的entity需要分成2种组件,可animatin和不可的?或者,外层使用组件都可包含skeleton组件和entity组件,添加entity组件时将查询skeleton.目前还没深入,但unity中,连bone都是作为一个组件存在的.组件设计,其实也是需要整个程序代码全面的支持的,对于大量基于外部代码的情况,不知道有什么好的方法?组件方法也不是万金油.代码组织不能单纯靠映射关系表现.unity中,同样也会有类&#;GameObject,Collider这样的基类出现.Bone如果也作为组件的话,个人觉得需要考虑(查了下,bone确实不是作为组件提供的).声明：此篇文档时来自于【狗刨学习网】社区，是网友自行发布的Unity3D学习文章，如果有什么内容侵犯了你的相关权益，请与官方沟通，我们会即时处理。更多精彩内容：www.gopedu.com
推荐整理分享Unity3d 组件设计的思考(unity ugui组件)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:unity3d里面有哪些常用组件,unity3d里面有哪些常用组件,unity ugui组件,unity3d里面有哪些常用组件,unity3d里面有哪些常用组件,unity3d基本组件,unity ui组件,unity3d里面有哪些常用组件,内容如对您有帮助，希望把文章链接给更多的朋友！
[置顶] Unity中对SQL数据库的操作 在Unity中，我们有时候需要连接数据库来达到数据的读取与储存。而在.NET平台下，ADO.NET为我们提供了公开数据访问服务的类。客户端应用程序可以使用A
如何在NGUI上显示粒子特效 最后碰到有人问，如何在NGUI的UI层上合理的显示特效，恰巧以前做过，就在此小述一下什么都不说了，直接上代码吧，相信识货的应该都可以看懂usingUni
Unity3D研究之角色控制器组件研究 Unity3D研究之角色控制器组件研究Unity3D封装了一个非常好用的组件来实现第一人称视角与第三人称视角游戏开发，我们称他为角色控制器组件，几乎不用
