我们可以看到，Browser和Page是没有系统默认属性的。因为这两个控件比较特殊，一般情况下，都会使用Class Name或者creationtime这两个属性来描述该对象，它们在O\I里可是没有的。Class Name可以从Spy里看到，说到Class Name我们也不得不回顾一下之前讲过的一个挺重要的知识点，就是Class Name必须要写成micClass。读者再返回看看在上一个小节中，描述Browser和Page的时候是不是使用了micClass？
接下来讲解的是Spy，Spy在描述性编程中也是经常被调用的，因为O\I用于定位所要描述对象的属性，而Spy就是定位描述属性的属性值，它们绝对是默契的搭档！描述性编程也就是因为有了它们，才可以应用起来，如来看看下面这张Spy图，如图1-189所示。
图1-189
本小节的内容相对比较简单，不过简单不代表实用性就不高，恰好是相反的！最后，告诉读者描述性编程可描述的属性都是封装接口属性，不是自身接口的属性，务必切记！
1.7.4 描述性编程的妙用以及与对象库编程的混搭
本人是不支持使用纯描述性编程的，DP的使用应审时度势且以实用的角度出发。前面也讲到过了，一般情况下，描述性编程应用在对象库编程无法完全满足需求的时候，以替补的身份去出色完成少额的任务。但是要遵循一个原则，那就是不到必不得已（对象库编程实在没法解决），绝对不要去使用描述性编程，千万要杜绝想使用了就随意使用的情况。这样做有什么好处？最大的好处就是可以使脚本一目了然从而增加了可维护性！当一段脚本中都是对象库编程，突然有一行出现了描述性编程，那即使过了几个月后再看脚本，我们也可以马上明白，当前步骤是比较特殊的，是对象库编程完成不了的。反之，如果不养成这个好习惯的话，那整个脚本的层次就会显得非常乱，时间久了一定分不清哪些使用描述性编程的语句属于没必要范畴，而哪些属于必要范畴。
接下来，就举一些项目中需要使用到描述性编程的案例。
（1）百度首页有很多相同的Link控件，如“新闻”、“网页”、“图片”等，全部添加到对象库很麻烦，那么该如何使用描述性编程完成？
首先，先来看下场景图，如图1-190所示。
图1-190
一个首页就有接近?20?个相同类别的控件（Link），虽然不多，但是一个个添加也够烦锁的，既然它们是完全相同类型的控件，那么使用描述性编程是一个上佳之选，下面来看这段脚本，看看是如何实现的：
|
Set baidu = Browser("micClass:=Browser").Page("micClass:=Page") Print Baidu.Link("name:=新闻").Exist With baidu Print .Link("name:=贴吧").Exist Print .Link("name:=知道").Exist Print .Link("name:=MP3").Exist Print .Link("name:=图片").Exist Print .Link("name:=把百度设为主页").Exist Print .Link("name:=搜索风云榜").Exist Print .Link("name:=About Baidu").Exist End With Set baidu = Nothing |
