关于委托的一些想法

月下临风

最近在写场景系统,又写了半个月,重写了2次,感触颇多.

在所有的设计当中,让我感触最深的就是委托的思想.
因为有了这个设计,所有的对象都将变的simple.

我举个简单的例子,比如我这个人,要吃饭,那我需要自己种菜吗?我要睡觉,我需要自己做床么?我要开车,我需要自己造车么?我要看病,我需要自己去做药么?显然都不会,我只所以存在,只是做程序而已,所以要描述我这个人,其实只用描述我是一个程序就OK了.

那么设计类的时候也是如此,比如一个Edit控件类,他在游戏里只是输入和显示的功能,一个摄象机类,他只是用来固定视角用的,其他的方面他们都不要去管.
不管是场景也好,UI也好,都需要动态创建,那么动态创建的话就需要从配置文件中将属性的值读入,那么读入写入属性数值这些事情是不是这些类要实现的呢?
刚开始我确实让这些类自己实现自己数值的读写,后来觉得太多余了,于是去掉了,直接将这些事情委托给IO组件去完成.
那怎么委托呢?
想想我们现实社会中是怎么委托的就很简单了.一个人要委托另一个人做事情,只要告诉他要完成的事情的信息和要求就可以了.
比如,我做了一些运动类,有Bezier曲线运动,圆周运动,等,当我的摄象机要做bezier运动的时候,直接将摄象机对象委托给Bezier就可以了,只需要告诉他,起点哪里,终点哪里,中间有多少个顶点需要插值,那么Bezier对象自己会计算出运动路线,根据摄象机自己固有的速度,完成整个运动过程.当然其他对象也可以委托Bezier对象完成这个动作.

还有关于属性值的读写,这个是非常重要的一个部分,因为不管是游戏里,还是其他编辑器都需要实现这个.
我特地将一个对象与他的属性分离开来,一个对象拥有一个属性对象的指针,到时候创建出自己的属性就可以了.
分离出属性的目的就是想让属性拥有自己的继承关系.
这样比如Wnd窗口类,如果要实现委托的话就简单了,只需要告诉IO组件,读或写,属性列表跌代器,就可以了.
Wnd::porperty  pPPt = MyWnd.Porperty();
io::XMLReader( pPPt , xmlElement );
io::XMLWrite( pPPt, xmlElement );
也可以这样.
io::Reader   ReaderObj.push( Task( pPPt, xmlElement ) );
建一个委托事物列表.

我知道委托这个东西由来以久,只是以前都没有真正接触过,没用到过.我现在觉得这个东西在对象众多的系统中特别有用,能将每个对象变成更简单.粒度更小的对象.
[em2] [em17]

tonykee

的确
委托也就是代理，简单理解：比如你要修东西，你不用直接找修理厂，你只需要找到商家就可以了，商家有保修承诺，会帮你去找修理厂修你要修理的东西。就相当于商家是生产厂家的代理（委托），如果这个厂家不能修，我换个厂家修，好处是能去除用户和厂家之间的耦合关系。联系程序来说明，a类通过b类调用c类，那么b类就是c类的代理（委托），a类和c类的耦合性就不那么紧密了。换个角度，c不见得就只能被a去使用，还可能被其他的类去使用，这样c类的重用性就体现出来了，再做点改进如果可以的话：b类也不直接调用c类，而是通过b类调用c类的接口就更恰当了。这种模式的确是编写代码里面很重要的模式，用的好，的确带来很多的好处，但是用的过多也不好，会让代码不容易读懂。主要从耦合和复用方面考虑来使用委托。

sjinny

看不懂……是否就是分而治之的思想？做单件事并做好？

月下临风

我说的不好，也许没有把自己的想法表达明白。
楼上说的差不多就是这个思想。
尽量保持一个类的独特性，就是说，每个类都有他存在的理由，就为了这个理由让他存在好了，其他的杂事如果他也需要涉及到，能委托的都委托掉吧。
不能说是分治吧，应该说是分工才对，就像现实的社会一样。
我觉得系统的设计应该是针对职能，和接口来设计的，而不该是完全面向对象的去设计。OO的设计，往往让人容易站在对象的角度去看问题，这样容易把对象看的很大很复杂，很多时候刚开始定义了一个类，可是不知不觉中，随着项目规模的扩大，变复杂，这个类的功能也越来越复杂。
我真正想表达的就是在设计的时候最好站在职责和分工的角度去看问题。

bigbook2000

不要随便杜撰或者发明已有的概念

scarlion

除了复用和低耦合，委托还能更好的隐藏不需要用户知道的类和函数。

sjinny

其实我一直有个问题：如何在“不需要用户知道”和“不允许用户知道”之间把握平衡……

congy

委托不一定能降低耦合，我们不能只看到委托方，还要看被委托方，实际上被委托方是必须要知道委托方的属性的，这其实也是一种耦合，所以我们要看实际需要，如果某个操作是许多对象都要做的事情，就可以实现委托，正像现实世界中因为需要修理的用户需求多了，自然要成立一个修理厂，但如果只有一个客户需要，就没必要为这个客户去建立修理厂，因为修理厂本身也是需要维护的。OOD 中的对象不能太多，对象粒度变小从另一个角度来说也意味着对象数量的增加，意味着管理复杂度的增加，所以这是一个权衡的问题。

月下临风

楼上的说的很对。
我觉得用委托的思想，主要目的不是为了降低耦合性，因为这里已经涉及到游戏的逻辑层了，一个逻辑需要其他服务模块提供服务，也正式那些服务（或叫支持类）存在的理由。我只想用更简洁的代码实现，而这种实现需要设计类和服务类的时候就要设计好，关键是以什么形式寻求服务和提供服务。
打个不是很恰当的比方，你要吃饭，你可以去餐厅，也可以叫外卖，甚至可以叫女朋友做饭。
而商家也提供了服务，也可以送外卖，而你的女朋友也可以为你做饭。
如果我一直是叫外卖，而且点的菜从来不变，那这样就很简单了，那样我就只需要把那份外卖单放在身边，肚子饿了直接按重拨，甚至连个话也不说对方就知道我要什么了。（就像commod一样）
难就难在你事先根本不知道，我今天是打算怎么吃饭的，也许看心情了。更郁闷的是，有时候突然想吃法国套餐，却不知道哪里有。。。所以这个时候就需要委托别人帮忙了。

还有我这里根据我个人的理解，我觉得代理是站在商家的角度说的，而委托是在用户的角度说的。
我想没有一个游戏比上帝创造的世界更复杂了，有时候看看这个世界也许得到启发。

月下临风

sjinny: Re:关于委托的一些想法

其实我一直有个问题：如何在“不需要用户知道”和“不允许用户知道”之间把握平衡……

我觉得你说错了，“不需要用户知道”更因该说成“用户不需要知道”。
可惜我到现在还不知道什么是“不允许用户知道”的？难道是正版软件的序列号么？
如果是怕破解，或被逆出来，或是被挂了，这些因该是技术上的问题，和设计没关系吧。