今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

完成任务十四的一部分
明天计划的事情：（一定要写非常细致的内容） 

完成任务十四
遇到的问题：（遇到什么困难，怎么解决的） 

关于拆分组件化的问题，要分配好每一个组件化的引入，是不是就要理解它的运行原理呢
收获：（通过今天的学习，学到了什么知识）

重新的看了下关于组件化

框架组件->高度重用 

关于模块化组件化，从“预整体”(抽象)中分解拆分出各个部分，然后组合成整体(实体)，每个部分有特定的功能，某个地方需要什么功能，直接一个可实现该功能的组件插进去即可。

如：造汽车吧，好，先是一辆汽车的设计稿(抽象，性能神马的都要考虑)，再N种零件(组件/模块)组合成汽车(实体),这里N种零件,经过工厂(Factory)处理，如轮胎，通过名字(接口)就知道其功能和使用地方了。

因为专业是.net，在写css时候或多或少受到影响，总想写最少的代码实现更多模块、更多功能，和其它种种，区别OOP特性看待下面说法。

非常一般情况下，写CSS是根据设计稿，从上至下、从左至右的过程一丝不苟写下来；

再，一般情况下，会根据界面中每一对象(结构)提取其(对象)特质的类型,如宽高、字体、内外边距、边框、图标和色彩…，进行拆分、整合，哪些元素信息可以封装起来，以便各结构只需通过一个类名接口引入，如果需要变换，只需修改封装的内部实现即可。

同时，共用声明为基类，派生子类继承其基类特质(颜色、字体、背景、边框等)和能力(内外边距、粗、斜等)，也可以加入新特征扩展或重写基类而‘新实现’，也可以通过接口实现多重继承。

在一个web页面里，各个模块之间关系紧密度不是很高(甚至无相关性、依赖性)，可以采用单一责任制，模块里分层分割到较细粒度，各个元素彼此紧密结合，如你实现字体、我实现色彩图片，他实现内外边距宽高…这种先把组件搭建好，然后通过组件组装页面的方式，代码移植、复用、维护和扩展都比较方便，出了问题也能快速定位bug，降低开发效率和成本。

注意事项：

上面所述是一个比较理想的可实现，分层分割的粒度务必把握好！粒度过于密集或粗犷都难以达到预期效果，

如：

<div class="leftBox bgGray bottomLine">

<span class="cBlue f12px">

更改层的位置、背景色、底部线和span的字体颜色大小，都要去修改页面，虽然不修改页面也能实现，但是会词不达意、混乱不堪，所以CSS样式模块化组件化粒度要有紧有松！

后语：上面文章是前几年写的工作总结，经过几年工作具体情况，发现CSS样式模块化组件化不是很容易，和网页风格以及设计师对布局的把握有很大关系，如果网页风格遵循只有几种布局、几种颜色、图片几种规格，那么模块化组件化CSS以及XHTML结构是可行的。如果页面比较混乱或复杂，只能是‘一丝不苟’的写了。

--------------------- 

作者：山茶树和葡萄树 

来源：CSDN 

原文：https://blog.csdn.net/xianghongai/article/details/38536895 

版权声明：本文为博主原创文章，转载请附上博文链接！

 header下面的日期工具栏需要作为独立的业务模块

 列表区域可以作为独立的业务模块，但是与主业务靠太近，不太适合

出发时段、出发汽车站、到达汽车站皆是独立的业务模块

一个页面被我们拆分成了若干个小模块，我们只需要关注模块内部的交互实现，而包括业务模块的通信，业务模块的样式，业务模块的重用，暂时有以下约定：

① 单个页面的样式全部写在一个文件中，比如list里面所有模块对应的是list.css

② 模块之间采用观察者模式观察数据实体变化，以数据为媒介通信

③ 一般来说业务模块不可重用，如果有重用的模块，需要分离到common目录中，因为我们今天不考虑common重用，这块暂时不予理睬