js是java script
成都创新互联自2013年起，公司以网站设计、网站制作、系统开发、网络推广、文化传媒、企业宣传、平面广告设计等为主要业务，适用行业近百种。服务企业客户超过千家，涉及国内多个省份客户。拥有多年网站建设开发经验。为企业提供专业的网站建设、创意设计、宣传推广等服务。 通过专业的设计、独特的风格，为不同客户提供各种风格的特色服务。
js物理弹性就是用js做的在网页上显示的比较逼真的让人感觉真的有弹性的窗口。
在javascript中并没有原生的创建或者实现接口的方式，或者判定一个类型是否实现了某个接口，我们只能利用js的灵活性的特点，模拟接口。
在javascript中实现接口有三种方式：注释描述、属性验证、鸭子模型。
note：因为我看的是英文书，翻译水平有限，不知道有些词汇如何翻译，大家只能领会精神了。
1. 注释描述 （Describing Interfaces with Comments）
例子：
复制代码 代码如下:
/*
interface Composite {
function add(child);
function remove(child);
function getChild(index);
}
interface FormItem {
function save();
}
*/
var CompositeForm = function(id, method, action) { // implements Composite, FormItem
...
};
//Implement the Composite interface.
CompositeForm.prototype.add = function(child) {
...
};
CompositeForm.prototype.remove = function(child) {
...
};
CompositeForm.prototype.getChild = function(index) {
...
};
// Implement the FormItem interface.
CompositeForm.prototype.save = function() {
...
};
模拟其他面向对象语言，使用interface 和 implements关键字，但是需要将他们注释起来，这样就不会有语法错误。
这样做的目的，只是为了告诉其他编程人员，这些类需要实现什么方法，需要在编程的时候加以注意。但是没有提供一种验证方式，这些类是否正确实现了这些接口中的方法，这种方式就是一种文档化的作法。
2. 属性验证（Emulating Interfaces with Attribute Checking）
例子：
复制代码 代码如下:
/* interface
Composite {
function add(child);
function remove(child);
function getChild(index);
}
interface FormItem {
function save();
}
*/
var CompositeForm = function(id, method, action) {
this.implementsInterfaces = ['Composite', 'FormItem'];
...
};
...
function addForm(formInstance) {
if(!implements(formInstance, 'Composite', 'FormItem')) {
throw new Error("Object does not implement a required interface.");
}
...
}
// The implements function, which checks to see if an object declares that it
// implements the required interfaces.
function implements(object) {
for(var i = 1; i arguments.length; i++) {
// Looping through all arguments
// after the first one.
var interfaceName = arguments[i];
var interfaceFound = false;
for(var j = 0; j object.implementsInterfaces.length; j++) {
if(object.implementsInterfaces[j] == interfaceName) {
interfaceFound = true;
break;
}
}
if(!interfaceFound) {
return false;
// An interface was not found.
}
}
return true;
// All interfaces were found.
}
这种方式比第一种方式有所改进，接口的定义仍然以注释的方式实现，但是添加了验证方法，判断一个类型是否实现了某个接口。
3.鸭子类型（Emulating Interfaces with Duck Typing）
复制代码 代码如下:
// Interfaces.
var Composite = new Interface('Composite', ['add', 'remove', 'getChild']);
var FormItem = new Interface('FormItem', ['save']);
// CompositeForm class
var CompositeForm = function(id, method, action) {
...
};
...
function addForm(formInstance) {
ensureImplements(formInstance, Composite, FormItem);
// This function will throw an error if a required method is not implemented.
...
}
// Constructor.
var Interface = function(name, methods) {
if(arguments.length != 2) {
throw new Error("Interface constructor called with "
+ arguments.length + "arguments, but expected exactly 2.");
}
this.name = name;
this.methods = [];
for(var i = 0, len = methods.length; i len; i++) {
if(typeof methods[i] !== 'string') {
throw new Error("Interface constructor expects method names to be "
+ "passed in as a string.");
}
this.methods.push(methods[i]);
}
};
// Static class method.
Interface.ensureImplements = function(object) {
if(arguments.length 2) {
throw new Error("Function Interface.ensureImplements called with "
+arguments.length + "arguments, but expected at least 2.");
}
for(var i = 1, len = arguments.length; i len; i++) {
var interface = arguments[i];
if(interface.constructor !== Interface) {
throw new Error("Function Interface.ensureImplements expects arguments"
+ "two and above to be instances of Interface.");
}
for(var j = 0, methodsLen = interface.methods.length; j methodsLen; j++) {
var method = interface.methods[j];
if(!object[method] || typeof object[method] !== 'function') {
throw new Error("Function Interface.ensureImplements: object "
+ "does not implement the " + interface.name + " interface. Method " + method + " was not found.");
}
}
}
};
何时使用接口？
一直使用严格的类型验证并不适合，因为大多数javascript程序员已经在没有接口和接口验证的情况下编程多年。当你用设计模式开始设计一个很复杂的系统的时候，使用接口更有益处。看起来使用接口好像限制了javascript的灵活性，但实际上他让你的代码变得更加的松耦合。他使你的代码变得更加灵活，你可以传送任何类型的变量，并且保证他有你想要的方法。有很多场景接口非常适合使用。
在一个大型系统里，很多程序员一起参与开发项目，接口就变得非常必要了。程序员经常要访问一个还没有实现的api，或者为其他程序员提供别人依赖的一个方法存根，在这种情况下，接口变得相当的有价值。他们可以文档化api，并作为编程的契约。当存根被实现的api替换的时候你能立即知道，如果在开发过程中api有所变动，他能被另一个实现该接口的方法无缝替换。
如何使用接口？
首先要解决的问题是，在你的代码中是否适合使用接口。如果是小项目，使用接口会增加代码的复杂度。所以你要确定使用接口的情况下，是否是益处大于弊端。如果要使用接口，下面有几条建议：
1.引用Interface 类到你的页面文件。interface的源文件你可以再如下站点找到: .
2.检查你的代码，确定哪些方法需要抽象到接口里面。
3.创建接口对象，没个接口对象里面包含一组相关的方法。
4.移除所有构造器验证，我们将使用第三种接口实现方式，也就是鸭子类型。
5.用Interface.ensureImplements替代构造器验证。
您可能感兴趣的文章:
小议javascript 设计模式 推荐
JavaScript 设计模式之组合模式解析
javascript 设计模式之单体模式 面向对象学习基础
JavaScript 设计模式 安全沙箱模式
JavaScript设计模式之观察者模式（发布者-订阅者模式）
JavaScript设计模式之原型模式(Object.create与prototype)介绍
JavaScript设计模式之工厂方法模式介绍
javascript设计模式之中介者模式Mediator
学习JavaScript设计模式之责任链模式
1、方法定义为static，直接类名.方法名调用；
如
class Main1{
public static function Add(j:int,i:int):void
{
Debug.Log(i+j);
}
}
Main1.Add(1,2);
2、new 一个对象，对象调用，如
var m:Main1 = new Main1();
m.Add(2,3);
3、GameObject.Find(),得到那个有这个脚本组件的GameObject，这个GameObject再GetComponent，得到script，scirpt再调用方法。
@JavascriptInterface public void showMessage(String url,String message,JsCallback object){ dialog_Exit(context,message,url,object); }//JsCallback
首先要确定，即使抛开游戏不论，一般的Web应用或者网站，完全用JavaScript开发也是可行的。比如ExtJS、webOS的Enyo等。但是主流Web开发很少采用全JS的方案。原因大体有以下几点：
1. 注重考虑那些无法运行JS的用户代理。
用
户使用不支持JS的浏览器（比如较老的手机浏览器），或者禁用脚本。当然你可以选择忽略这一小撮用户，尤其是现在绝大多数网站和应用也是如此选择的，但是
至少我们应该对坚持考虑无JS情况的开发者予以基本的尊重。此外，如 Mobile
Transcoder或某些手机浏览器的“极速模式”是基于服务器端对网页的解析和重组，是否能支持JS很够呛。
更重要的因素是SEO friendly。如果是全JS生成的网页，搜索引擎无法索引内容。这一点对于许多网站是性命攸关的。
注意，有人提到screen reader。但绝大多数读屏软件是根据DOM来的，因此全部由JS生成DOM也不会有问题。然而这前提是JS所生成的DOM是符合accessibility要求的。
2. 注重HTML/CSS本身的优点。
诚然JS本身也可以通过精心设计的框架和库来实现分离等所有HTML/CSS模型的优点。但是存在许多不确定因素：
1) 有足够好的框架和库吗？
要
考虑是否能满足你的业务需求，还可能要考虑性能、可扩展性、之前提到的accessibility、学习曲线、工具链，乃至此框架和库的长久的生存（有人
维护，修bug、加新功能比如对HTML5新API的支持之类的）。关键是，理论上说JavaScript具有更高的弹性，但是更大的自由度未必能得到更
好的
2) 框架和库给出的抽象模型和HTML/CSS模型的阻抗是否匹配？
假如该框架或库本质上仍然使用HTML/CSS模型，只是改变了语法（比如从markup改为json），那么其提供的好处在哪里？仅仅是语法统一？
如
果该框架或库有自己独立的抽象层，比如widget/component等，那么它是建筑在HTML/CSS之上的额外抽象层（即最终映射到HTML
/CSS），还是仅仅以HTML/CSS为纯粹实现工具？对于前者，实际上最终会回归HTML/CSS模型。而后者，可以参考的经验教训就是 WebForm和JSF。
3) 框架和库所设定的约束能否在开发中一以贯之的执行？
无
论是理论或者现实，HTML/CSS模型都算不上完美。但是至少是清晰和较容易被一致的执行的。但是单一语言即使提供分层机制，也容易被绕过——尤其是框
架和库本身不够好的情况下，可能由于不能满足需求、有bug等情况而倾向于hack之，更不要说deadline紧迫时。
3. 注重性能。
须
知，最终Web应用、页面是在浏览器中执行，而浏览器完全是按照HTML/CSS所设计。抛开Canvas不论，纯JS的实现最终还是要生成DOM。从性
能的角度看，纯JS生成DOM自然赶不上直接的markup。同样的道理，就算用CSS预处理器也都会在部署时预先编译——尽管在运行时可以做出更牛逼的
特性（然而实际上目前我不知道有任何CSS预处理器干了这样的事情——因为它们都是按照预编译的场景设计的），再如HTML/CSS是按照渐进显示优化的
（页面不用全下载完就可以看部分），而纯JS的架构没有精心设计是很难做到的（比如json数据全部下载完你才能parse，数据才可用，DOM才能生
成）。
［补充：尽管LESS是可以在运行时执行的，但是从性能的角度出发是不合适的，因为CSS通常必须在页面rendering之前就全部就位。而运行时产生CSS，
就要求在页面rending之前至少要先下载执行LESS的脚本，然后解析编译你的.less源代码。这个性能开销至少目前还不容忽视。］
［补
充：性能优化的另一点是基于HTML/CSS的声明性特点，即只表明high-level的目标，浏览器才能获得更大的优化自由度。比如CSS
transition/animation，与JavaScript通过修改style达到效果比，前者性能表现要好得多。］
4. 注重Web开发的独特特点。
1) HTML/CSS 都是声明式的，也就是其本身并不希望是程序员来编程。当然，一个编程语言能干所有的事情，但是即使考虑编程本身，为什么在通用编程语言之外还要有SQL、还有以各种语法写的配置文件？
2) HTML/CSS是基于标准的。这与 WebForm、JSF、Flash/Flex等私有技术或一个语言和平台下的标准有天壤之别。具体就不展开了。
3)
Web开发和一般应用开发有个重大区别是，Web应用、网页的最终表现和行为，或者说Web的用户体验，并不是完全由开发者决定的，而是开发者和用户共同
决定的。用户选择不同的设备、不同的浏览器、不同的浏览器设置、不同的浏览器扩展等，都能影响结果。这是缺点，也是优点。看你如何体会了。这里具体不展
开。只是一点，纯JavaScript开发通常表示你想更多的控制用户体验，但这并非简单的多写代码就能做到。
js防水涂料施工方法如下：1. 基面处理：基面必须坚固、干净、平整、湿润；基面有孔隙、裂缝等缺陷的，预先用水泥砂浆修补抹平；阴阳角用抹刀修成半圆角；确保基面充分湿润，但无明水。
2. 材料配比：JS弹性防水乳液：水泥=1：（0.6-0.8）的重量比混合，充分搅拌至不含颗粒、均匀的胶浆状即可使用；在使用过程中要保持间断性搅拌，以防分层沉淀。
3. 施工：用毛刷或滚刷直接涂刷在基面上，力度使用均匀，不可漏刷；若用于防潮，只需涂刷一层；用于防水，需涂刷二至三层。当第一层干固至刚好不粘手时（一般须1-2小时），即可涂刷第二层，每两层涂刷方向应垂直相交。
4. 涂层保护：浆料施工完毕后，未完全干固前须对涂层进行必要的保护，包括禁止行人、雨水冲蚀、暴晒、尖锐物件损伤等；完全干固后的涂层不需要做特别的保护层。
5. 涂层养护：涂层施工完毕24小时后建议用湿布覆盖涂层或喷雾洒水对涂层进行养护，一般2-3天；空气湿度大，通风不良的地方干固时间会较长。
6. 检查（闭水试验）：卫生间、水池等部位请在防水层干固后（夏天至少24小时，冬天至少48小时）储满水48小时以检查防水施工是否合格。轻质墙体须做淋水试验。选择合适的防水涂料，推荐考虑下科顺防水科技股份有限公司。公司于北京、上海、深圳下设工程公司，拥有专业工程技术人员超过370人，年均为近3000个项目服务，在多个重大建筑项目的防水工程项目中，均采用了科顺标准化施工，为670多个施工现场提供技术咨询和施工指导。其中最早成立于1998年的深圳市科顺防水工程有限公司，拥有国家建筑防水一级防水保温资质。
公司目前已是“中国建筑防水材料工业协会”及“中国建筑业协会防水工程技术专业委员会”的常任理事会员，并多次获得中国建筑防水行业最高工程奖一“金禹奖”荣誉。
