加法运算符:

• 运算数是NaN、undefined，则结果为NaN
• Infinity加Infinity，结果为Infinity
• -Infinity加-Infinity，结果为-Infinity
• Infinity加-Infinity，结果为NaN

减法运算符：

• 运算数是NaN、undefined时，结果为NaN
• Infinity减Infinity，结果为NaN
• -Infinity减-Infinity，结果为NaN
• Infinity减-Infinity，结果为Infinity
• -Infinity减Infinity，结果为-Infinity

乘法运算符:

• 运算数是NaN，结果为NaN
• Infinity乘以0，结果为NaN

除法运算符:

• 运算数是NaN，结果为NaN
• Infinity除Infinity，结果为NaN
• 任何数除Infinity，结果为Infinity
• 0除非无穷大的数（Infinity），结果为是NaN

取模运算符:

• 运算数是NaN，结果为NaN
• 除数是0或者被除数是Infinity，结果为NaN
• Infinity除Infinity，结果为NaN
• 除数是Infinity，结果为被除数
• 被除数是0，结果为0

我们每时每刻都在设计，无论是工作还是生活。在工作中，程序设计的深度直接影响着项目的工期和质量。

这个道理浅显易懂，每个人也都会在工作中掌握自己的设计，但每个人的都会认为自己的设计是适度的，那么如何判断一个设计究竟是适度设计还是过度设计呢？

最近，自己做了一些项目，也遇到了这样的困惑，在大家的帮助下，稍微总结了一下过度的特点，希望能有一些价值。

1、分成与耦合程度
在做一个基于前端表现产品时，为了追求解耦，为了追求分层，将其中的功能分成不同的模块。这种思想本身是没有问题的，但过犹不及，同学们对自己的产品期望过高，甚至希望产品可以适用到绝大多数产品上，但结果往往是为了解耦而预留了过多的接口，代码臃肿不堪，不易改变，维护成本居高不下。因此，适度设计的产品应该把握，按需解耦，根据需求重构代码。

2、过多的依赖库，框架
有的时候，前端产品需要处理一些兼容性问题，因此必不可免的要写一些兼容性代码，为了方便，在有的设计中出现了过度引用第三方框架的问题。第三方框架的引入，在前期是一种解决兼容性问题行之有效的办法，但是随着时间的增长，第三方类库进行升级，bug修正。此时的第三方类库，就成为了后期维护的炸弹。同时，因为语言写法上的差异，在维护第三方类库的时候将会投入比修正兼容性问题更多的时间与精力。因此，保持代码纯净，只使用一个类库或者不使用类库，坚持代码语法规范，命名规范，格式规范是重要的。

3、为了设计而设计
有的时候，开发人员会经常接触到各种设计模式，这些设计模式，好比一座座工厂，将解决问题的方法批量的告诉我们，但工厂毕竟是工厂，他只能满足那种常见的固化需求，当需求灵活多变的时候，固化的设计模式所起到的作用就适得其反。

这只是我一些不成熟的想法，希望有这方面经验的同学多多交流。

在现在的软件设计上，基本上采用的都是分布式系统，前端尤其突出，回忆一下，我们将CSS、JS独立到不同的CDN或独立静态池上，我们将图片放到专属的图片服务器上，这都是分布式系统的体现。我们的交互界面，我们的后端程序乃至数据库都存储在各个不同的服务器上，最终，通过计算机网络将它们连接起来。

因为采用了分布式系统，前端开发中也遇到了分布式系统本身的问题，比如说分布式系统节点的广泛带来了复杂的部署环境，比如分布系统组件的协同工作会因延迟、过载、甚至失效而带来的不稳定性。

以往，我们在前端开发过程中，为了避免这些分布式系统所带来的问题，采用了各种方法，比如下图中，某网站采用将js直接写入页面中的方式避免上述问题。（当然我也可以认为这段代码是开发人员偷懒直接复制进去的， XD）

view-source:http://news.sina.com.cn/c/2010-11-15/191121475156.shtml

让我们试想一下，某天下图中的接口地址变更，开发人员需要更新数万页面以保证页面工作正常，即便是拥有了各种分发机制，甚至使用重写或者301转向，也是一种维护成本高的工作方式。

为了解决分布式系统所带来的问题，各公司都引入了不同的解决方案，最典型的解决方案就是中间件。

在国内的各大主流网站中，我们不难发现类似下面的代码，从而从不同的网络节点中获取到对应的组件

上述代码是一种直接写入N个SCRIPT标签的变体，他的本质是通过getFileVesion()获取参数数组中的路径，循环建立SCRIPT/LINK对象后再插入到页面中，我们称呼这种中间件为对象计算中间件，它给我们的开发过程带来很多便利，前端工程师采用面向对象的方式编写各种组件来降低整个开发流程的复杂度，并且可以灵活有效的进行分发以提供可重用的功能。

虽然分布式对象计算中间件成熟稳定，但它也存在着一些不足，例如，当我某一个对象/组件依赖于其它对象/组件时，这两个对象需要明确对方已经载入，因此开发人员需要设计代码来实现这种对象与对象，组件与组件之间的关联，开发人员需要判断这些组件是否已经loadReady，或者组件内部需要判断他需要的对象是否已经加载。

与此同时，分布式计算中间件没有提供给我们一个标准化的方式去启用不同的组件，当我们需要停用旧的组件、增加新的组件时，修改原有组件就需要手动的去维护要增加的内容。例如，上图中，当我需要增加一个获取cookie的方法时，也许我就要增加xxxx/js/getCookie.js，甚至，我还要给他提供一个版本号来标识版本以及清除分布式系统的缓存。

那么为了解决计算中间件的上的缺陷，设计人员开发出一种称为组件中间件的技术，组件中间件通过一个组件对象来实现不同组件的调用以及管理。

组件中间件中，组件是功能实现的实体，他提供了一套方法以及连接点，以便不同的组件之间互相协助。方法可以是require也可以是add，甚至是when i needed … download，连接点就是需要载入组件的路径，在这种组件架构中，定义良好的关联关系存在于组件中间件与需要载入的对象中间，因为这种关系的存在，所以，我们可以通过组件定义、构造、加载、剔除所需要的对象，而对象也可以被要求预载入，触发事件时载入等等。

同时，组件中间件提供了对接入点的预定义，我们可以通过配置组件来达到加载不同服务节点，不同版本的对象。

虽然中间件拥有很多益处，但对于分布式系统而言，中间件也有不可靠的地方，当系统宕机时，当网络缓慢甚至断开时，中间件就无法保证所需要的对象被加载，因此在中间件的设计上也需要考虑各种可能出现的错误，并做好容错机制保证前端的页面的呈现。

多态性就是多种表现形式，具体来说，可以用”一个对外接口，多个内在实现方法“表示。举一个例子，计算机中的堆栈可以存储各种格式的数据，包括整型，浮点或字符。不管存储的是何种数据，堆栈的算法实现是一样的。针对不同的数据类型，编程人员不必手工选择，只需使用统一接口名，系统可自动选择。 百科链接

我理解了下，js下应该是这样来实现

var Car = function(type){
   return new Car[type]();
}
 
Car.jeep = function(){}
Car.jeep.prototype = {
    showType: function(){
        return "this is jeep";
    }
}
 
Car.bus = function(){}
Car.bus.prototype = {
    showType: function(){
        return "this is bus";
    }
}
 
var jeep = new Car("jeep");
var bus = new Car("bus");
 
jeep.showType(); // this is jeep
 
bus.showType(); // this is bus

不过要是都这么写，可能就累死了，maybe…

今年十一终于回家了，阔别六年的家乡变化真大~

姑且不说条条大道通我家，单是无数塔吊就让我心旷神怡，毕竟在集团公司里面长大的孩子对各种各种都很有爱。

老家的小吃实在便宜，一顿胡吃海喝才花了68元，68686868….难道我是在团购么？

离别数年的热干面，春卷，豆皮，无数有爱的食品又吃了一次，小时候吃的黄桥烧饼让我超有爱，买了25个在列车上吃…

家乡正是橘子收获的季节，神马广柑啊，神马香蕉啊，各种进口啊，统统死去，家乡的大蜜桔真的很好吃，真的很好吃，真的很好吃…

真的很有爱，就连无线网络的密码都是12345，真的很有爱！！！

美中不足的是房价高的吓人~

明年还要回去…买房！