日历

September 2020
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

Reply To: 冒号老师,如果有人这样问你,你会怎样回答?

Home Forums 《冒号课堂》讨论区 冒号老师,如果有人这样问你,你会怎样回答? Reply To: 冒号老师,如果有人这样问你,你会怎样回答?

#1358
hui
Keymaster

这是个很好的问题,而且是个很实际的问题。你的意思我完全明白,事实上你的解释已经很接近问题的本质,只是没能用更理论化的语言表述而已。

抛开性能因素,用array的做法之所以不合适,原因很简单,即数据没有结构化,类型没有语义化。说到底,是数组类型过于底层,没有抽象的封装。即使不是OOP的fan,我们也可简单地通过夸张array的做法来看出其不合理性:按这种思路,array不仅可替代NameValuePair这样的二元组,还可替代三元组、四元组、N元组。如果这样,C中的struct、union,C++、Java、C#等中的class等的作用也大打折扣了。

编程语言一代代进化,一个重要标志就是语言的抽象性更强,语义的表达力更丰富,用array来实现NameValuePair是一种开倒车的做法。当然,如果为了性能优化,或临时、局部地应用,这也不是完全不可取。为了性能原因,程序员(尤其是C程序员)甚至会把一个整数的每一个bit都赋予特殊的意义,换言之,把整数当作bit array来使用。只是单从设计的角度看,这类技巧的缺陷是很明显的。因为一个数组中元素所代表的意义没有显式的表达,只是隐藏在非常原始的数组下标上,降低了代码的可读性和可维护性。比如,用户可能写错下标,或者不慎造成下标越界。此外,这种做法对需求变化的适应性很差,如果以后需要为NameValuePair array增加新的属性或行为,会极大地影响客户代码。如果采用NameValuePair class,则会大大减少代码修改量。还有一个很现实的问题:前者修改的范围不仅大得多,而且也难找得多。因为array太普通,不易定位。而如果采用NameValue的命名结构,在代码中搜索起来也快得多。

此外还有另一个语义问题:数组的一般用法是各元素是同类型的,这种类型不仅是语法类型,而且是语义类型。NameValuePair中name一般是string类型,value则未必。即使也是string类型,它们在语义上也是不等同的。如果一定要用通用的底层来表示,那么tuple也比array更合适一些。比如Python便支持tuple,与array最大不同的是,tuple可以是异构的,并且是immutable(不可变的)。当然,如果语言(比如javascript、ruby、php、python等)直接支持key-value类型,自然最好不过,只是我们讨论的前提应该是这种类型不被语言原生支持。

 请您评分1星(很差)2星(不行)3星(一般)4星(不错)5星(很棒)