<<编写可维护的javascript>> 笔记5(UI层的松耦合)

由于第四章太稀松平常了, 于是就直接跳到第五章了.
这里我就草草的说一下第四章的几个点吧

1. 在严格模式的应用下 不推荐将"use strict;"用在全局作用域中
2. 相等. 推荐尽量使用===和!==
3. eval(). 守则如果是在没有别的方法来完成当前任务, 这时可以使用eval()
4. 原始包装类型. 不推荐创建类型时用String、Number等创建类型.

---

从这一章节开始就迈向了我们变成实践的部分了.

5.1 什么事松耦合
很多设计模式就是为了解决紧耦合的问题. 如果两个组件耦合太紧, 则说明一个组件和另一个组件直接相关, 这样的话, 如果修改一个组建的逻辑, 那么另一个组建的逻辑也需要修改. 比如, 结社有一个名为error的CSS类名, 它是贯穿整个站点的, 它被嵌入到HTML中. 如果有一天你觉得error的取名并不合适, 想将它改为warning, 你不仅需要修改CSS还要修改用到这className的HTML. HTML和CSS紧耦合在一起. 这只是一个简单的例子. 想象一下, 如果一个系统包含上百个组件, 那这简直就是异常噩梦.

当你能够做到修改一个组件而不需要修改更多其他组件时, 你就做到了松耦合. 对于多人大型系统来说, 有很多参与维护代码, 松耦合对于代码可维护性来说只管重要. 你要绝对希望开发人员在修改某部分代码时不会破坏其他人的代码.

当你哥大系统的每个组件的内容哟了限制, 就做到了松耦合. 本质上讲, 每个组件主要保持足够瘦身来确保松耦合. 组件知道的越少, 就越有利于形成整个系统.

有一点需要注意: 在一起工作的组件无法达到"无耦合"(no coupling). 在所有系统中, 组件之间总要共享一些信息来完成各自的工作. 这很好理解, 我们的目标是确保对一个组建的修改不会经常影响其他部分.

如果一个Web UI是松耦合的, 则很容易调试. 和文本或结构相关的问题, 通过查找HTML即可定位. 当发生了样式相关的问题, 你知道问题出现在CSS中. 最后, 对于那些行为相关的问题, 你直接去找JavaScript的问题所在, 这中能力是Web界面的可维护性的核心部分.

---

到这里感触颇深, 对于现在项目各种组件化开发项目对于组件的依赖和优化有着密不可分的关系, 如果你的组件写的足够松耦合的话, 这样对于开发者后期的维护和bug的修改以及新功能的添加来说可以用喜大奔普来形容了. 我在这里可以提供一种方法来设计组件化.

你可以将你的项目主要划分为两种组件, 一个提供各种方法啊执行条件啊获取数据等等的功能另一个只需要来展示它所想要表达的内容. 你只需要将正确的数据传递至展示组件即可.

5.2 将js从css中抽离
在IE8和更早版本的浏览器中有一个特性让人爱少恨多, 即CSS表达式(CSS expression). CSS表达式允许你将JavaScript直接插入到CSS中, 这样可以在CSS代码中直接执行运算或其他操作.

/* 不好的代码 设置元素宽度以匹配浏览器宽度 */
.box {
    width: expression(document.body.offsetWith + "px");

}

CSS表达式包裹在一个特殊的expression()函数中, 可以给它传入任意js代码. 浏览器会以高频率重复计算CSS表达式, 严重影响性能, 甚至在<高性能网站建设指南>也特意提到这点, 避免使用CSS表达式!

5.3 将css从js中抽离
尽量不要直接在js中操作DOM元素的style属性来修改样式. 会对你的项目维护造成很大的麻烦.
比较好的方式就是操作CSS的className, 也就是说你再CSS中定义好类名, 在js中操作元素的className即可.
就是不应当直接操作样式, 以便于保持和CSS的松耦合.