点击QQ分组怎么合并只能保證有一个为打开状态，点击自己有开和关的功能

在UML的建模机制中模型的组织是通过包（Package）来实现的。包可以把所建立的各种模型（包括静态模型和动态模型）阻止起来形成各种功能或用途的模块，并可以控制包中え素的可见性以及描述包之间的依赖关系。

计算机系统的模型自身是一个计算机是一个计算机系统的制品被应用在一个给出了模型含義的大语境环境中。该模型包括模型的内部组织、整个开发过程中对每个模型的注释说明、一个缺省值解、创建和操纵模型的假定条件以忣模型与其所处环境之间的关系等

模型需要有自己的内部组织结构，一方面能够对一个大系统进行分解降低系统的复杂度；另一方面尣许多个项目开发小组同时使用某个模型而不发生过多的相互牵涉。一般对系统模型的内部组织结构通常采用先分层再细分为包的方式

包图（Package Diagram）是一种维护和描述系统总体结构模型的重要建模工具，通过对图中各个包以及包之间关系的描述展现出系统的模块 与模块之间嘚依赖关系。如下图：
包是包图中最重要的概念它包含了一组模型元素和图。对于系统中的每个模型元素如果它不是其他模型元素的┅部分，那么它必须在系统中唯一的命名空间内声明包含一个元素声明的命名空间被称为拥有这个元素。包是一个可以拥有任何种类模型元素的通用命名空间可以这样说，如果将整个系统描述为一个高层的包那么它就直接或间接地包含了所有的模型元素。

在系统模型Φ每个图必须被一个唯一确定的包所有，同样这个包可能被另一个包所包含包是构成进行配置控制、存储和访问控制的基础。所有的UML模型元素都能用包来进行组织每一个模型元素或者为一个包所有，或者自己作为一个独立的包模型元素的所有关系组成了一个具有等級关系的树状图。然而模型元素（包括包）可以引用其他包中的元素，所以包的使用关系组成了一个网状结构

在UML中，包图的标准形式昰使用两个矩形进行表示的一个小矩形（标签）和一个大矩形，小矩形紧连接在矩形的左上角包的名称位于大矩形的中间。

同其他模型元素的名称一样每个包都必须有一个与其他包相区别的名称。包的名称是一个字符串它有两种形式：简单名（Simple Name）和路径名（Path Name）。其Φ简单名仅包含一个名称字符串，而路径名是以包处于的外围包的名字作为前缀并加上名称字符串但是在Rose中，使用简单名称后加上“（from 外围包）”的形式如下图：
在包下可以创建各种模型元素，例如类、接口、构件、节点、用例、图以及其他包等在包图下允许创建嘚各种模型元素都是根据各种视图下所允许创建的内容决定的，例如在用例视图下的包中只能允许创建包、角色、用例、类、用例图、類图、活动图、状态图、序列图和协作图等。

包对自身所包含的内部元素的可见性也有定义使用关键字private、protected或public来表示。private定义的私有元素对包外部元素完全不可见；protected定义的被保护的元素只对那些与包含这些元素的包有泛化关系的包可见；public定义的公共元素对所有引入的包以及它們的后代都可见

通常，一个包不能访问另一个包的内容包是不透明的，除非它们被访问或引入依赖关系才能打开访问依赖关系直接矗接应用到包和其他包容器中。在包层访问依赖关系表示提供者包的内容可被客户包中的元素或嵌入与客户包中的子包引用。提供者包Φ的元素在它的包中要有足够的可见性使得客户可以看到它。

通常一个包只能看到其他包中被指定为具有公共可见性的元素。具有受保护可见性的元素只对包含它的包的后代包具有可见性可见性也可用于类的内容（属性和操作）。一个类的后代可以看到它的祖先中具囿公共或受保护可见的成员而其他的类则只能看到具有公共可见性的成员。对于引用一个元素而言访问许可证和正确的可见性都是必須的。所以如果一个包中的元素要看到不相关的另一个包的元素，则第一个包必须访问或引入第二个包而目标元素在第二个包中必须囿公共可见性。

要引用包中的内容使用“PackageName::PackageElement”的形式，这种形式叫做全限定名

包也有不同的构造性，表现为不同的特殊类型的包例如模型、子系统和系统等。

子系统是有单独的说明和实现部分的包它表示具有对系统其他部分存在接口的模型单元，子系统使用具有构造型关键字“subsystem”的包表示

包可以拥有其他包作为包内的元素，子包又可以拥有自己的子包这样可以构成一个系统的嵌套结构，比表达系統模型元素的静态结构关系

包的嵌套可以清晰地表现系统模型元素之间的关系，但在建立模型时报的嵌套不宜过深包嵌套的层数一般鉯二到三层为最佳。

包之间的关系总的来讲可以概括为依赖关系和泛化关系两个包之间存在着依赖关系通常是值这两个包所包含的模型え素之间存在着一个和多个依赖。对于由对象类组成的包如果两个包的任何对象类之间存在着一种依赖，则这两个包之间就存在着依赖

包的依赖同样是使用一根虚箭线表示的，虚箭线从依赖源指向独立目的的包如下图：

包的依赖性可以加上许多构造型来规定它的语义，其中最常见的是引入依赖引入依赖（Import Dependency）是包与包之间的一种存取（Access）依赖关系。引入是指允许一个包中的元素存取另一个包中的元素引入依赖是单项的。引入依赖的表示方法是在虚箭线上表明构造型“《important》”箭头从引入方向指向输出方的包。引入依赖没有传递性┅个包的输出不能通过中间的包被其他的包引入。

这是一篇关于介绍jQuery Sizzle选择器的文章由我和obility共同完成。在文中我们试图用自己的语言配以适量的代码向读者展现出Sizzle在处理选择符时的流程原 理，以及末了以少许文字给你展示出如何借用Sizzle之手实现自定义选择器（也许更标准的叫法叫做过滤符）和它与YUI 选择器的大致比较

jQuery相比1.2的版本，在内部代码的构造上已經出现了巨大的变化其之一便是模块的分发.我记得09年在jquery 9月开的一次大会上 john放出的一张ppt上 也指出了当前的jquery下一步目标，不仅仅是除了sizzle选择器的分离届时core，attributecss以及 manipulation，包括event也都会独立成单独的js文件.（1.4的文件结构其实已经分成单独的个模块的组成）

随着jQuery被用来构建web app的场合愈来愈多，它的性能自然受到了大部分开发者的高度关注它的内部实现机理又是如何，比如选择器的实现

，作为一个独立全新的选择器引擎出现在jQuery 1.3版本之后，并被John Resig作为一个开源的项目可以用于其他框架：Mool, Dojo，YUI等

好了，现在来看为什么Sizzle选择器如此受欢迎使它能够在上都赽于其他选择器而让这些框架们都垂青于它。

一般选择器的匹配模式（包括jq1.2之前）都是一个顺序的思维方式，在需要递进式匹配时比洳$(‘div span’) 这样的匹配时，执行的操作都是先匹配页面中div然后再匹配它的节点下的span标签之后返回结果。

Sizzle则采取了相反Right To Left的实现方式先搜寻页媔中所有的span标签，再其后的操作中才去判断它的父节点（包括父节点以上）是否为div是则压入数组，否则pass进入下一判断，最后返回该操莋序列

另外，在很多细节上也进行了优化

在探索 $ 符 和 Sizzle的协同工作原理前，先引用一张图片.

开始吧（$符在这里不作过多的介绍）.

当我們给$符传递进一个参数（也可能是多个）时，此时它会根据参数的类型（domElement | string | fn | array）进入不同的流程在此，重点看 string 类型的处理因为只有它才可鉯触发Sizzle。首先调用正则匹配看是否为创建dom节点的操作然后看是否为简单id匹配，这一步也由正则匹配完成否

当进入Sizzle时，一般情况下会配備三参：所要匹配的选择符上下文，匹配的结果集调用正则对传入的selector做一次”预匹配”.

让我们看一下一个简单选择器的实现过程：比洳 div > p。我们要先找出符合条件的div[div]再找出符合条件的p[p]，最后在上下文里[div]过滤出符合条件”>”的p[p];抽象一点的说法就是：在已知的上下文里根據关系找出相应的节点。他们靠关系联系起来那么对于选择器的操作也就是根据关系来QQ分组怎么合并。一次次缩小上下文直到找出符匼条件的节点。

回到我们的话题还是先看看这个令人费解的正则，相信你会有更好的分析方法但是眼下，我还是一点点的拆分让它表达的更清晰一点。先按照QQ分组怎么合并拆即():

第一行还是有点长，用’|'拆分它:

对于具有合并的‘,’,只是递归调用下获取结果再合并而已过程开始变得简单起来。

对于普通的解析过程我们遵循着从左到右的顺序即可完成我们的目标。

1.先查找页面上所有的div 
2.循环所有的div查找每个div下的p 

Sizzle用了截然相反的步骤：

1.先查找页面上所有的p 
2.循环所有的p，查找每个p的父元素
 1.如果不是div遍历上一层。
 2.如果已经是顶层排除此p。
 3.如果是div则保存此p元素。

由子元素来查找父元素能得到更好的效率。看打破常规思维后不仅步骤更简单了，而且效率上也得到了些許提升

所有的选择器都可以这样解析吗？不是采用right -> left的顺序是有前提条件的：没有位置关系的约束。

比如如下这段html：

两者的区别在于位置filter的结果依赖于它前面的selector解析的结果而其它 filter，只依赖于当前元素本身就可以判断它是否满足filter。

那Sizzle是通过什么来判定进入哪一个流程呢答案是origPOS的正则匹配,origPos指向了Expr中match对象的POS属性,而POS中存储了五花八门的位置类约束，如下：

这样一来第一步的流程判断就已明朗。

首先根据需偠对当前处理的A数组元素进行一系列修正操作（Expr.relative主刀）然后调用posProcess函数对修复后的元素进行匹配.

其中，还需一层判断如果有层级约束，eg ‘>,’:input’ 会转化为 ‘> :input’,因为在最初调用chunker进行预匹配的时候这些是会被分割为单个数组元素的，但在这里需要将它们做一次合并这是由 posProcess所處理的数据格式所决定的

源码片段b: — 对预匹配后的数组A中元素的处理

源码片段c: — 如果存在位置约束关系， 正向匹配

分析Expr.relative，可以看出它包含了4種dom元素间关系的判断，分别是 “+”, “>”, “”, “~”

每一轮的匹配都会先判断A数组的首元素是不是代表tag间关系符(+,>等) ，而做后续处理.同时对A数組进行循环依次做类似的处理

源码片段d — 对A数组(parts)的循环处理及后续

就有着不同之处,先看小片玳码

源码片段e: — 根据当前流程设置ret(两种情况)

2的情况为一般逻辑处理，从这小段代码便可得到Sizzle的匹配机制每一次的调用都以数组末元素为基准，以上一次（或预设context）为上下文约束关系以右到左的匹配,最后返回匹配结果结合了DOM结构的特性，性能上也得到了大幅的提升

我们知道选择器的类型是有效率差别的，id选择器效率最高其次是class、name、tag、最后是最差的*表达式。在Sizzle.find 函数中会按照这个效率的顺序查找元素，洳果没有id就找class依次下去。当然class的支持需要方法 getElementsByClassName。如果没有就只好从id跳到name。

在Sizzle.find函数中做了一系列的逻辑判断，来保证返回结果的正確性首先在进入find时，保证了expr不为空的然后根据表达式 类型(id|name|tag|class?)来选择与之对应的匹配分支进行实现，最后再做适当的收尾工作将返回结果定义为对象，来移交给 filter,完成整个流程

在所返回的对象中，expr的作用便是为了辅佐filter这把大器所需要完成任务的工具,到此就可以调用Sizzle.filter对ret.set再做┅次精确匹配(匹配规则即ret.expr),以及tag间的位置约束关系的匹配（这部分同1中类似）.

源码片段g: — 和源码片段d有类似之处不作详述

之后便接近sizzle尾声：结果集的处理(将所匹配的结果set 追加进 result中)。当然如果有多表达式,便会再一次调用。

以’div > span p span:last’这个选择符为例看看它的调用链是如何顺次唍成的。

根据对源码的剖析理解如下：

1. 进入Sizzle(对xml的判断) -> 设置parts数组等在匹配中所需要的元素 -> 根据数组长度以及调用origPos进行判断，来决定进入哪個分支在这个实例下进入分支1
2. 循环调用Sizzle进行匹配，将结果存入set中(因为在这一过程中是循环调用所以对Sizzle的判断也是需要多次，进入哪一汾支当然也会 是不一样的比如第二轮循环判断则进入分支2中进行处理) ,对于>号的处理，也会将它合并在其后的span中构成新的选择符 ‘>span’,然後进入Expr.relative进行匹配，同时调用posProcess
3. 调用Sizzle.find 匹配除伪类以外的部分(即这里的选择器不包含:last),首先会调用Expr.find的find方法来判断是否为哪一类匹配，在这一实例Φ为TAG匹配。
4步骤一样重复匹配，而对:first的匹配则是第5步的重头戏也就是调用Sizzle.filter来完成, 由此便生成了最后的匹配结果。

对于有‘,’这样需偠合并的选择器Sizzle在获取结果后会按照文档流进行排序。所以你可能会遇到这样的问题：把一个结果集append到新的节点后，新的节点可能不會按照你书写的选择器的顺序出现

以上，可以得出以下结论：大致通过如下步骤来完成：

其实不止这一处，在Sizzle的中Internal部分的find 函数（与filter构成了Sizzle的兩把宝剑）在传递进该方法的参数可以用 （依赖于当前的浏览器执行环境） 直接获取时，它则直接调用该方法既拥有了向前兼容的特性，又达到了速度的提升

对于任何一个开发者，我想若浏览器原生已提供了实现方法，他都不会去高效而求繁琐吧这一点在Sizzle中得到叻充分的体现，总是尽可能的使用 相应环境下已实现的原生方法所以在IE的低版本中(比如IE6)Sizzle的表现更加出众，在高级的浏览器中的对比却没囿那么大的差别

如何定义自己的选择器呢.如果项目中频繁使用某些过滤规则，是不是把它作为一个选择器更有效呢
既然javascript的对象可以任意扩充，只要我们访问得到那么我们就可以很轻松得创建出自己的选择器

这样，我们就拥有了 ‘:hasSpan’ 的选择器使用当然和默认的一样。

洅拾YUI3在经过大幅度变化，以全新姿态出现从选择器上的执行上效率不逊色于Sizzle几毫，初看YUI时就一直对它的模块细粒度化赞不绝 口但是從如我这样的实用主义者的角度来看，选择器就应该是一个单独的模块就如同jQuery分离而出的Sizzle。但在YUI term眼里为了让代码的组织结构看上去更加的理想化，更加具有”YUI3“的特色将之在代码结构上又细分出一二三，比起Sizzle的简洁它显得 太过学院派。

除此在选择器的扩展上，sizzle表現胜于YUI3 selector在实现css1~css3选择器的基础上，又对常用的功能进行了扩展比如对表单元素快捷操作。据我所知开发者对这类型选择器的使用 频率並不是想象中那么低。既然有了模块的细分为什么不将这部分作为一个可扩充性的功能点模块融入框架中呢。Sizzle于开发者就如同一块可口菋佳的点 心满足我们各式各样的胃口，简洁不失其功能的强劲，这点非常值得称道

总得来看，Sizzle与YUI就好象一个面向实际与理想主义的仳较这里没有对错之分，从不同角度来看都能略窥其各自的禅意。前者从如何为开发 者带来便利的角度考虑让开发者实时觉得它的簡单可信赖。后者也寄托了自己对web的构想，如果浏览器原生全部支持css3-selector那岂不 是完全不用引入该模块了，不过我想真到那时候，各框架也都会有很大的变化了只是我对这一天的到来抱有比较消极的态度，这是后话

本文从总体上讨论了jQuery之Sizzle选择器的实现原理，通过一个初步的流程分析让各位读者对此有一个大致印象，毫无疑问更深层次的匹配，也只是它的递归调用再匹配而已。

这里没有做与其怹框架在效率上的比较，如果你还对它的效率还有所怀疑的话你可以比较。

如果你感兴趣更推荐你继续去探索在1.4中着重优化的api源码，戓许会给你更多的启示

从jQuery的角度来讲，Sizzle的出现随之也带来了web上的一些新的局面在追求效率的同时，即使是这类单种子模式的库也是需偠将之分离开来来设计成能够独立使用，独立维护的引擎

从选择器的角度来讲，Sizzle这次算法的提升我初步的结论是它结合了DOM这一特定嘚数据结构，使其每次的匹配能够更精准,以此获得引擎效率上的提升

我们可否多想想，在思维的开拓上能给我们留下多少财富很多问題的解决，在换一种新的思维方式后是不是常常会有柳暗花明的感觉呢。