以前看过模块化的相关资料以及解释，对模块化有了一个表皮的了解，自己也做了一些相关的实践，由于接触到的项目交小，所以也没能更好的去体现和理解模块化，但总体还是有那么一些感悟，但是如果要说怎么才能算是好的模块化，自己内心还是一个疑问。
前几天接到一个电话面试，谈到了css模块化的问题，觉得自己的回答太模棱两可，自己回答过后对自己的答案也不满意，没有一个周全的思考和考虑。
下面总结一下自己对css模块化的理解，尽可能的表达完善自己的想法以及对所查找到的资料的一个总结。
——————————————————————————————————————————————
1. 什么是模块化
百度词条解释的“ 模块化 ”：
“模块化是指解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。每个模块完成 一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。模块具有以下几种基本属性：接口、功能、逻辑、状态，功能、 状态与接口反映模块的外部特性，逻辑反映它的内部特性。在软件的体系结构中，模块是可组合、分解和更换的单元。”
我们所借鉴的是一种思维的方式。
2. CSS面向对象思想
封装、继承、多态
封装：表意即包装，要点就是不同的特性抽象到一个基于类的模块里，封装是实现CSS模块化的最基本要求，封装成的各个单元就是基本的CSS模块，可灵活用于组建页面的各种显示样式。
css中的继承：指我们设置上级(父级)的CSS样式，上级（父级）及以下的子级（下级）都具有此属性
多态：多态主要用于同一模块在页面的不同部分或者不同页面之间呈现出不同的样式。
例如：我们可以将按钮这一类型封装成button类，但是会发现这一个button类并不会满足一个网站内所有按钮的样式，这时候我们就要观察按钮的样式，将按钮的公共样式提取出来，然后根据不同的需要再添加另外一个类，比如公共样式的类名为“btn-default”，蓝色的为“btn-info”，绿色的为“btn-successful”（这是借鉴bootstrap中的，也即多态），特殊需要也可以写类覆盖掉公共类中的一些样式，根据他的权值大小，。
但这样写出来的模块化也有弊端，有时候自己想想也都觉得矛盾（前台人员在写页面时挺方便使用，但是在后期维护中，需要调整样式，就不是在css里调整，而是可能需要到html结构中去调代码，甚至需要多处调整，也不便于维护）
2. CSS组织方式
目前见过有几种组织方式
base.css（reset功能，底层） + common.css（组件级的CSS类，中间层） + page.css（提供页面级的样式，高层，page层是页面级的，每个页面都可能会有自己的page层css）
这种第一次尝试写的时候，公共样式提出来放入common中，多态的放到哪？页面都可能会有自己的page层的放入page中，common和page层写着写着自己就完全混乱了，为什么混乱？因为公共样式和多态分开了，多态的放到哪？有时候自己都忘记了自己写的代码都在什么地方，哪一块是怎么样的，多态出来的或许可也把多态的放入一个新的css里，总之归结自己经验还太浅太浅。
header.css+container.css(中间可再细分)+footer.css+print.css+ie.css
此种划分以自己理解就是因为后台人员在处理时，往往是把头部和底部抽出成一个公共结构，然后各个页面都引入这个结构，（对于后期的维护是相当有效的， 因为涉及导航栏的修改仅需修改一次即可）
此种的弊端是什么？自己虽然不是处女座，但是如果一个页面内样式很少，一个超级多，自己内心也是崩溃的，少的你不浪费资源吗？感觉这个，头部和底部可以共用一个css文件，至于container，觉得全都装在这里面，不好找，还容易造成很乱的感觉，感觉可以在此基础上再分出来几个，可以结合第一种的组织方式
3. CSS如何划分模块——单一职责原则
从视觉上进行划分，样式和功能相对独立且稳定的一部分就可以视为模块，将这些相似的部分提取出来，再进一步拆分成更小的模块，模块与模块之间尽量不要包含，相同的部分，如果有相同部分，应将它们提取出来，拆分成一个独立的模块。应将模块拆得尽可能简单，以提高弹性。
第一次尝试这个时候，自以为还行，结果后来客户需求不明确，整个网站各个板块样式布局都要改，那叫一个惨不忍睹，血泪史，最后用继承和多态思想解决掉了。
4. 聚合/组合
这个建议查看http://blog.csdn.net/hacke2/article/details/21707133，很多都是借鉴此博主的，里面加了一些自己的主观感受，现在自己还不太确定，到底是挂多个calss还是新建的好，所以自己选择适当就好（缺少大项目经验啊，缺少对网站优化的经验）