封装的表面
其实封装,字面解释就是封起来装好,事实上也确实是这样子的
比如一个函数
function myFunc(a,b){
return a+b;
}
很明显myFunc的用处就是返回两数的和
那么
myVar = myFunc(1,2);
myVar就等于3.
这之中就做到了封装,因为当你要得到两个数相加的时候你只要调用myFunc();然后把你要相加的两个数传进去就可以了,具体myFunc是怎么加的,你根本不用知道.这样子就达到了封装的作用.当然加法谁都会做,所以这么做显然有点哗众取宠^^"
那如果让你计算由两个电阻并联组成的电路中,总电阻是多少呢??
ok,如果你的电学学的很棒,想都不想就知道了,但是你的电学和我一样,不怎么样,或者说糟透了的话.我们还是用一下别人封装好的函数就行了
function Resistance(r1,r2){
if((r1+r2)==0) trace("错误:分母不能为''''0''''");
else return r1*r2/(r1+r2);
}
R=Resistance(5,10);
这样子,就不用去管它什么要命的电学公式,只要调用一下Resistance();并把你知道的两个电阻值传进去就搞定了^^
怎么样,封装是不是很好理解,形象一点就是:
你把一组数据传到一个黑箱中,在经过这个黑箱后得到的另一组数据,之中黑箱就是封装了的函数
而此中黑箱的入口,就是函数的参数....
只要知道入口是什么就行了,你管黑箱怎么造的,结构怎么样呢
封装的内涵
确实,一个不懂电学的人当然不会公式
因为以上只是讲了封装的概念,并没有去说封装的用处,就封装的概念而言,上面的说法应该可以接收了,现在我只得用封装的用处,或者说好处来解释^^
封装的好处,其实也是显然的,你的这个函数就可以给别人使用啊,比如你写了一个计算电阻的公式函数,ok,你写好后不管你用什么方法,告诉给一个不会的人,那么那个人只要像上面说的,调用一下函数就解决了.
说的具体一点gotoAndPlay();这个函数人人会用,但是知道它内部怎么执行的人不多,除非你研究过:),因为macromedia公司把他封装好了,并给出了接口,你只要知道他的接口,也就是黑箱的入口,传递个正确的参数进去,就行了.
所以说,创造封装函数和使用封装函数是两回事情......
封装的进步理解
(感谢dingding帮偶总结)
封装的大致用途就是,把一个函数做好封装后,以后到哪里都可以用这个函数,只要知道这个函数派什么用处,理解接口就可以了,不需要知道函数是怎么做的.
比如 你会不会用gotoAndPlay(); 呢？会吧,他就是一个MM公司封装好了的函数,你确实不知道具体怎么执行的吧
先讲下接口的概念，还是用gotoAndPlay()为例,你来告诉我怎么用？
呵呵你会告诉我gotoAndPlay(1)
那么里面的1就是这个函数的参数 当然除了这个参数,你还知道gotoAndPlay()有别的参数么？
你会回答我 有比如gotoAndPlay("XX帧标签") gotoAndPlay("XX场景")
就是因为这几种参数,就是这个函数对外的接口
我们只知道 gotoAndPlay(10) 时间轴就跳10帧播放
而gotoAndPlay（）这个函数里面到底是怎么运作的,我们不需要知道,
只要知道它提供我们的接口是什么,然后通过这个接口我们能干什么就ok了
比如,你自己写了个函数
function moveToRight(mc){
mc._x++;
}
moveToRight就是封装函数,mc就是对外接口
这个函数你随便拿到哪里,只要给它传递一个mc参数就可以了
moveToRight 是函数名 mc是参数
下面我们举个例子来说说封装函数和没封装的函数的区别与好处所在
function reSet(){
_root.mc._alpha = 50;
}
reSet()
//或者mc.onEnterFrame = moveToRight;
是不是就达到把MC的ALPHA的效果了?? 这个方法好不好呢？
也许你会说，没什么不好呀 首先申明了一个函数 然后又调用这个函数。思路很清晰呀！
但是难道真的觉得它很好么??
呵呵,其实它一点不好 为什么？
试想一下,如果你的mc的名字突然要换了,换成 myMC,你还是要达到你要的效果,你该怎么做
是不是要找到这个函数,把mc换成myMC
改2个地方 第一：帧上 第二：MC的命名
然后你又突然发现,要让场景中的其他5.6个mc也达到用样的效果,又该怎么做 ？
是不是在函数里面反复的加上 _root.mc1._alpah=50;_root.mc2._aplha=50;......
是不是很笨的方法？ 如果你聪明,ok,你会想到在函数里面建立一个循环
for(var i = 0 ;i<5;i++){...}
呵呵 但当你不止有5个,有6了呢,是不是就又要改了?
到头来,你场景中稍微有点改动,你就要潜千辛万苦的去找reSet函数,并反复修改
也就是说,这个函数再别的文件里面,一点用处都没有,还要针对其他源文件的情况
而改变,只是为了要场景中的一些mc的透明度到50,就要不断的修改函数内容
如果你承认,这么做很傻,那么你就要学会去封装函数
其实最简单的办法,你为函数建立一个参数（注意：这里mc是参数了,而不是原来场景中实例的引用 ）
function reSet(mc){
mc._alpha = 50;
}
那么你要哪里的mc透明为50,只要把这个mc的名字传入参数就可以了
比如,你的场景里面有6个mc,名字为mc1~mc6;那么
reSet(mc1);
reSet(mc2);
reSet(mc3);
reSet(mc4);
reSet(mc5);
reSet(mc6);
就算你有600个也不用怕,用一个循环就搞定了
for(var i = 1; i<=600;i++){
reSet(this["mc"+i]);
}
这样,这个函数就活了,哪怕你这个项目结束了,下个项目中,仍然要使用到
把某些mc的透明设置为50,只要再用这个函数就ok了
这个函数就是所谓的封装好了的函数,参数mc,就是你对外的接口
不管你场景中的mc怎么变化,从头到尾,你都不需要去改变函数里面的内容
呵呵 也许你还没明白吧 那我们再来举个实际点的例子
比如,你要搬家了,那么建立一个搬家函数,要命的是你雇佣的装修大队,设计队长写了这么个搬家函数
function 搬家(){
沙发.位置 = 靠墙;
床.位置 = 角落;
桌子.位置 = 靠窗;
}
此时当你如果多了一个椅子的时候,你是不是要找到搬家的函数,然后添加一下 椅子.位置 = 靠门???（位置随便说的）
这么做是不是太麻烦了,那个装修大队的设计队长,每次在你对家具摆设不满意的时候,就要重新修改自己写好的搬家函数-w-
如果那个队长帮50户人家设计过同样的函数,那当其中一家人家出问题了,他还要去找,对应它的搬家函数来修改,简直是虐待自己....
但是,我们换一个装修队,他们的队长这么设计了一个搬家函数
function 搬家(家具,地点){
家具.位置 = 地点;
}
这么做是不是就解决了问题
搬家(桌子,靠窗);
搬家(床,角落);
搬家(椅子,靠门);
....
其实封装的意义,就是把不改变的东西隐藏,把改变的东西暴露
封装的好处就是可以让,程序耐用,多用,维护便利等
上面那个搬家函数,不管你搬50户人家,100户人家,用那个一个函数,就统统搞定了,是不是要方便很多
我想设计出这么一个搬家函数的设计队长,一定比之前那个队长好过的多,呵呵
总结一下:
"封装是一个概念,是一个良好的程序思想,是一个良性的编程方法"
=×××××××××××××××××××××××××××××××××××××观点2×××××××××××××××××××××××××××××××××=
学习设计模式的人常说“封装变化”。变化，应当怎么封装？设计模式那么多种，可以采用多种封装方案，如何判断一个封装方案是好是坏？
答案：看封装后系统演化时，修改点是否唯一而定。
说得直白一些。当系统需要扩展一个功能时，你要修改的地方是多了还是少了？少了就说明封装得好。
封装的最高境界是：以后增加一个功能，只需要修改一个地方就行。
下面，我举一个封装失败的例子来说明这一点。
此例子来自一个实际应用的P2P网络应用项目。在网络项目中，需要定义多种协议数据包，以此来互相通讯。这里的变化趋势是很明显的：随着系统的发展，数据包的数量会有增减，原有数据包的字段也有可能增删。
现在的问题是，如何将这些变化封装起来？下面是一个程序员实际使用的方案。
1. 最初编写网络程序,以结构体来进行协议编码,解码
struct GPRSInboundMsg
{
PROTO_HDR Header;
UBYTE_t arUnitAddr[UNITADDR];
INT32_t iEventTime;
UBYTE_t pMessage;
};
2. 这种协议是比较常见协议,带有基本数据类型,数组,和不定长的成员,如果直接使用结构体进行协议数据的编码,解码,很容易因为字符串拷贝,内存申请,释放这些常用操作带来问题, 下面使用类来封装该协议:
class CPtoOutbMsg{
public:
void SetUnitAddr(const BYTE_t *pAddr);
void SetMessage(const BYTE *pMsg);
virtual int Pack(char *pPointer, const char usBufLen);
virtual int UnPack(const char *pPointer, const char usBufLen);
private:
PROTO_HDR Header;
UBYTE_t arUnitAddr[UNITADDR];
INT32_t iEventTime;
UBYTE_t pMessage;
};
这个方案很简单，就是用对象来代替结构体，并且将结构体的成员全用函数封装起来。
设计者解释他这样做的目的是，避免直接操作这些字段引起的内存越界等问题。从这个角度来说，设计者这样的封装是达到目的了。可惜的是，设计者忘记了封装的目的：减少修改点。
我们看看这种封装方案对系统的影响。
直接使用结构体的方案时，某个数据包增删一个字段，需要修改的地方有：
1、修改结构体；
2、修改所有引用该结构体的地方（删除字段需要，增加字段就不用了。但如果系统有某些特殊需求，如计算可变长度数据包的实际长度，那么这些地方也可能要修改。）
而经过上面封装之后，对于同样的需求，需要修改的地方有：
1、修改结构体（同上）；
2、修改所有引用该结构体的地方（同上）
3、修改该数据包对象的函数（增删两个该字段相应的读写函数）
4、修改Pack函数（打包函数）
5、修改UnPack函数（解包函数）
增加数据包也是类似的，即除了增加相应结构体之外，需要相应创建一个结构体封装对象：每个字段的读写函数，打包解包函数等等。
现在很清楚了，这种封装是失败的。它为系统修改带来了不止一倍的开销。
使用这样的封装，带来的后果是比较严重的，每次协议修改，都会让修改者累个半死（想想一个字段的变动，要修改五个地方！）。程序员必定强烈反对修改协议，或者产生怠工情绪。
最后总结：
一个封装方案成功与否，看封装后系统演化时，修改点是否唯一而定。
=×××××××××××××××××××××××××××××××××××××××××补充一点：××××××××××××××××××××××××××=
设计模式还没有看过，因为水平还不够。但是看到这个是因为封装函数引起的。通过函数封装可以隐藏细节和代码复用。两点结合后总结如下。函数本身应该是一个处理工厂，有数据的输入和数据的输出，并且不需要因为输入数据的改变而重新改建工厂（即工厂本身与数据是分离的），如果工厂的处理是需要可变得（例，工厂可以计算两个数据的和，也可以计算两个数据的积），这必须是简单的通过指令（参数）可控的。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
