在使用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中,同样也会有类似GameObject,Collider这样的基类出现.
对于需要依赖很多第三方库的程序,我觉得组件设计不是一个好的选择.绝大多数第三方c++库,使用的还是类继承系统,你无法完美的与你的组件系统组合在一起,甚至就是矛盾的.抽象程度越复杂的第三方库,越无法进行这种合作关系.
