联动列表框，简简单单的五个字，仅仅从字面上看，就可以分出来两个职责：
职责一：列表框
职责二：联动
我们先来看这两个职责，然后再说引申出来的另外两个职责。
职责一，列表框。列表框分为很多种，比如下拉列表框（DropDownList）、列表框（ListBox），还有为了美观用div模拟的，以及RadioBoxList，CheckBoxList等。首先一个问题就是，用哪种列表框，然后是其ID、name等属性的命名规范。然后是列表框是怎么出来的？是写死在body里，还是用js动态创建出来，还是其他的什么方式？
这些都属于列表框的职责。这些都和联动没有任何关系。不联动，他们也都存在。
再来看职责二，联动。联动指的是两个或者多个列表框直接的关联关系，比如常见的省市区县联动。省份的下拉列表框change之后，城市的下拉列表框要显示选择的省份里的城市，城市改变了之后，区县下拉列表框的选项也有随之变化，这就是他们的联动关系。
联动就是说，谁和谁有关系，谁change了，哪个要跟着变化。
职责三：页面布局。多个列表框如何摆放？是紧挨在一起，还是在各自的td里，还是在div里？还是离着很远（中间有其他字段）？这是页面布局的事情，就是如何办法控件，而一个表单里不仅仅只有联动列表框，还会有文本框、其他列表框等。这些控件如何摆放？
职责四：数据获取。这里特指获取列表框的选项（option、item），因为有的时候一次性全部加载的话，数据量太大，比如省市级联，几百多条数据；省市区县级联，数千条数据；如果是省市区县街道级联，呵呵，一般好像没有这个需求（城市、区县、街道的话，是可以滴）。正因为数据量比较大，所以大多数采用ajax的方式获取，选择辽宁省，就加载辽宁的城市，其他的不加载。
但是如果联动的数据量很小的话，也这么做就有点折腾了，一次性加载也没多少压力，可以避免多次访问，给IIS带来的压力。
那么到底如何获取数据？还有要不要做缓存？都属于这一职责，当然，如果又需要，还可以细分为多个职责。一切看需求、环境，没有固定不变的。
好了，四个职责都说我了，我们来做个假设。假设我做了一个联动列表框，他可以自己动态创建列表框，你输入3，就动态创建三个列表框，你输入10，就创建10个列表框。而且这些列表框可以出现在任意指定的位置，出现在哪里随你指定，还可以自己去获取需要的选项。当然了，联动功能就不必说了。如果我弄出来了个这样的东东，肯定会有人站出来说：这个耦合性太高了，一点都不灵活，不符合某某，违反了某某，blablabla。不信的话可以看我以前发的博文。
把这些职责和在一起，做成一个控件的缺点是啥呢？牵一发而动全身。比如我一开始用的是下拉列表框，后来客户说，面积太小看这不方便，换成列表框吧，这个面积的，一次可以看到多个选项，不想下拉列表框，用鼠标点一下才能看到其他的选项。那么怎么办呢？我要改联动列表框。但是这个需求变化，和“联动”有啥关系？
再比如，我一开始是把所有选项都一次性加载到页面，然后change的时候，筛选出来需要的数据作为选项。在局域网里面没啥问题，但是到了外网，速度就很慢，客户不干了要改。咋办呢？改成ajax的吧。我又的去改联动列表框，但是这个和联动有啥关系呢？
再比如，我一开始是把几个联动列表框挨在一起，一个挨一个，省市联动是没啥事了。但是后来遇到个需求，两个列表框离着挺远，中间隔着几个控件，咋办呢？我还得改联动列表框，但是同上的问题。
这就是让一个控件负责多个职责的缺点。
那么分开来有啥好处呢？
我可以写一个js，专门负责动态创建各种列表框，比如下拉列表框等等。
在写一个js，专门负责数据提取。
再来一个js，专门负责表单里的控件的布局。
最后一个js，就是负责联动。
这样分开来之后呢，职责就明确多了，联动部分做好了之后就不用去改了（前提是接口设计的合理、健壮）。而且还很容易分工，我可以找四个人，一人负责一部分，四人一起开发，提供开发速度。
就着联动列表框，说了说单一职责，也顺带提了几嘴开闭和低耦合。其实这几个都是相辅相成的。一个做好了，其他的也就自然而然了。
ps：写了两个多小时，才写了这么点字，速度太慢了。
