设计的核心任务之二:信息隐藏

假使说我们认同软件的构造是一个复杂的过程,那么管理这种复杂度必然需要一些技巧。而为了找出这些技巧,则需要先瞄一眼这种复杂度的基本构成。

 

 

软件的构造过程牵涉了两个最为基本的要素:一是软件,一是构造软件的人。

假设说存在着一个标准的人,这个人智力水平恒定,创新能力恒定,技能水平恒定。那么软件的复杂度只决定于其自身,比如软件所需要面对的业务规则,所需要的计算水平等。应对这类复杂度的有效手段是优化方法,好比说快速排序的效率大多时候就是比冒泡排序好。

 

当我们开始考虑人的可变因素时,复杂度的来源则发生了变化。人是有着许多与生俱来的特质的,比如说:人是会犯错的,人同一时间可以处理的事情是有限度的。因为这些特性,人在应对软件自身所拥有的复杂度的同时,又带来了偶然的,与个人特质相关的复杂度。比如说:局部变量的名称可能碰巧和一个全局变量相同,而我们又误把这个局部变量作为全局变量使用了。

 

信息隐藏则是减少这类偶然性复杂度的一个有效手段。

对于方法或函数而言,输入参数,输出参数描述了它的边界。

对于类而言,公有属性和公有方法描述了它的边界。

边界以内的即是被隐藏掉的信息。

 

 

假设说我们用一个名为CustomerManager的类来管理客户的基本信息,但在开放出AddCustomer(), EditCustomer(),DeleteCustomer()这样接口的同时,也开放了内部存放客户信息的集合类。那么使用CustomerManager类的人,很可能直接通过操作集合类来获取客户信息。这个做法虽然可以被编译器所接受,但实际上是对CustomerManager类的误用。为了避免这类误用,存放客户信息的集合类应该被隐藏起来,让用的人只看到接口。

 

信息隐藏是抽象数据类型,类等之所以存在的一个比较主要的理由。但信息隐藏并不只在使用抽象数据类型和类的时候才有意义。定义接口的时候,甚至实现的时候信息隐藏这一原则同样可以发挥作用。

比如说:实现方法A的时候,实际上只需要类的两个属性,但却把整个类定义成了这个方法的参数,这也是违背信息隐藏原则的。

 

 

还有一种比较有意思的情况是,目的是信息隐藏,但实际上却违背了信息隐藏原则。

比如说:类的方法中常常会使用到成员变量。有时候和类自身关联不是很紧密的属性也会被添加为成员变量。像表征数据库的类,比如DataBase,大多时候并不需要和获取数据的类,比如传感器的类Sensor直接关联,但有时候Sensor的实例却会被添加为DataBase的私有成员变量。

 

与此同时,大多时候类中的方法并不会把成员变量作为自身的参数,而是会直接使用,比如说:由于Sensor的实例是DataBase的私有成员变量,那么DataBase::GatherData()在用到Sensor实例的时候会直接使用,而不会把接口定义为.DataBase::GatherData(Sensor& sensor )。这种用法与成员变量过度膨胀的趋势撞在一起后,有意思的事情发生了。

 

从外部看,传感器这样的成员变量是私有的,达到了信息隐藏的目的。

但对于方法而言,结果却完全相反。

每多使用一个成员变量,其自身的信息隐藏就被破坏一点 。

 

如果在同一方法中,用到五六个成员变量,那么这个方法会变得非常难懂。因为对于类中的方法而言,这些成员变量自身的变化是完全不被隐藏的,每个都有有自己独立的脉络,比如说:DataBase::SetInterval()方法中可能会调整Sensro实例的状态,进而对Sensor::GatherData()产生影响。这会导致方法的边界不清晰。不清晰,也就不可能紧凑。不紧凑意味着阅读的时候,一个方法所需要的信息不能立刻获取。最终会导致程序难读,难改,难维护。

 

这类实例提醒我们,并非把很多操作和数据成员都放到类里面就达成了信息隐藏的目的。

事实上这对每个类的可能规模提出了限制。极端的情况下,如果一个类很大,有2000SLOC,那么所有这2000SLOC代码就等于通过成员变量粘结在一起,这和过度使用全局变量在一定程度上等价。

 

从信息隐藏的程度上来看,对方法而言,局部变量最佳,类的成员或属性稍差,全局变量最差。

局部变量把信息隐藏在方法之内,成员或属性把信息隐藏在类之内,而全局变量等于不做信息隐藏。

 

 

 

信息隐藏和前面提到的层次问题并不能分割开来。从基本趋势来看,信息隐藏做的越彻底,层次也必然就会越多。而前面曾经提及过层级自身是有副作用的。

 

从最小化层次的副作用的角度来看,使用函数或方法来隐藏数据,使用类似抽象数据类型的方法来把数据封装到类之中,代价非常微小,几乎总是对的。但在类A中包含B,类B中包含C,类C中包含D这类的方式则福祸难料。诚然B,C,D被隐藏了,但绝不是毫无代价。

 

 

--------------------------------------------------------------

 

理想流 + 软件 = 《完美软件开发:方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质,追求真理。

 

posted on 2012-04-18 00:03  理想流  阅读(2197)  评论(1编辑  收藏  举报