十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
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年的深圳市科顺防水工程有限公司,拥有国家建筑防水一级防水保温资质。
公司目前已是“中国建筑防水材料工业协会”及“中国建筑业协会防水工程技术专业委员会”的常任理事会员,并多次获得中国建筑防水行业最高工程奖一“金禹奖”荣誉。