随感协作开发的JS设计模式

从最原始需求出发，我们必须有一个最简单的实现类，这个类必须是可继承的。方便之后不同的业务需要做不同的扩展。我们必须确保这个类的稳定性。

简单实现类的定义：鼠标点击触发某容器，不带任何辅助效果。我们来想想，这么简单的一个类，需要包含哪些方法，搭个骨架出来：

  1. AP.widget.basic = new AP.Class({
  2.   setOptions:function(options){
  3.     //接口设置
  4.   },
  5.   initialize:function(targets,options){
  6.     //初始化方法，目的是建立targets子集元素和某方法的关联 
  7.   },
  8.   getVessel:function(target){
  9.     //获取满足target映射关系的容器 
  10.   },
  11.   bindEvents:function(target,vessel){
  12.     //这里绑定target的触发动作
  13.   },
  14.   action:function(){
  15.     //target绑定的事件触发的执行函数，包含你要执行的逻辑 
  16.   },
  17.   show:function(){
  18.     //显示容器 
  19.   },
  20.   hide:function(){
  21.     //隐藏容器 
  22.   },
  23. })

这是所有满足本文定义的简单实现类所需的基本方法，我们可以将它作为一个基础方法，方便满足简单类定义的交互形式在此基础上扩展，然后我们开始归纳常用的满足简单类定义的交互形式，如：tab切换，气泡提醒，下拉列表，xbox……

  1. AP.widget.aPop = AP.widget.basic.extend({
  2.   bindEvents:function(target,vessel){
  3.     //重写绑定target的触发动作
  4.   },
  5.   action:function(){
  6.     //不同的场景，会有不同的交互需求，所以我们可以重写该方法，满足不同的需求   
  7.   },
  8.   setTip:function(vessel){
  9.     //设置一个气泡小尖角，插入vessel容器 
  10.   },
  11.   delTip:function(el,vessel){
  12.     //去除这个小尖角 
  13.   },
  14.   setCloseTip:function(vessel){
  15.     //如果气泡绑定的是click事件，设置关闭按钮 
  16.   }
  17. });
  1. AP.widget.xTab = AP.widget.basic.extend({
  2.   bindEvents:function(target,vessel){
  3.     //重写绑定target的触发动作
  4.   },
  5.   action:function(){
  6.     //不同的场景，会有不同的交互需求，所以我们可以重写该方法，满足不同的需求   
  7.   },
  8.   oXtab:function(target,e){
  9.     //初始化tab 
  10.   }
  11. });

这个类，我们可以抛开业务需求，简简单单的实现最基础的交互形式，相信这个脚本已经能满足日常中60%的需求了，当然这对于一个业务极其复杂的公司而言，是远远不够的，所以重点来了，在面临多变的需求和复杂的业务需要时，我们该如何应对？

假设接到一个新需求：需要做一个形如支付宝首页广告切换的效果，通常大家会是怎么样一个思路呢？我想应该是重新定义了一个类，堆了一堆的方法进去，对于一个团队协作的JS开发模式来说，这种做法并不幽雅

我们基于上面的规划，首先你的大脑终端扫描，对比，定位要实现的这个新效果，在简单类中是否有相似的原型。结果很显然，那么我们接下去要做的只是针对首页特殊的交互效果，基于简单类中的xtab做一个继承扩展，形如:

  1. AP.widget.xTab = AP.widget.xTab.extend({
  2.   action:function(){
  3.     this.parent();//继承简单类中action的基础操作逻辑
  4.     this.addEffect();
  5.   },
  6.   addEffect:function(){
  7.     //需要添加的效果逻辑 
  8.   }
  9. });

这样做的好处在于，避免不同的业务场景下不同的需求把我们的基础组件撑的越来越大，降低耦合度过高带来的修改风险。当然这种模式也很大程度的提升了开发效率。

说到这里，抛个个人看法，YUI，实在不是最理想的团队JS开发协作模式，至少个人觉得不适合目前支付宝前端开发团队，或许我们应该反思一下我们某些组件中闭包的应用是不是不合时宜…

未完，待续…

Tags: , ,

[RSS 2.0] [留下宝贵的意见]



过客留言 该主题有10条留言

匿名

这是一个比较有意义的课题，期待更多人的发言

2010年1月星期25 [ 05:17 ]

匿名

老鱼已经站在更高的角度在看问题了哦

2010年1月星期25 [ 06:52 ]

asta

牛人啊，膜拜~~

2010年1月星期25 [ 07:32 ]

sos

i want your twitter baby

2010年1月星期25 [ 07:35 ]

匿名

有点启发，我好好想想

2010年1月星期25 [ 07:56 ]

匿名

啥叫大局观，哈哈，老鱼你行的

2010年1月星期25 [ 10:25 ]

xiongll

恩，看了以后有少少的感触，关注ing

2010年1月星期25 [ 13:46 ]

匿名

这个看看还是不错的,一直都关注楼主的文章.

2010年1月星期26 [ 13:47 ]

yakexi

老鱼的文章亚克西…

2010年2月星期18 [ 01:53 ]

老鱼在线»Blog Archive » 再议构建前端UI组件的新思路

[...] 近日，看了玉伯写的《构建前端UI组件的新思路》一文，让我追忆起去年自己分享的一篇P文《随感协同开发的JS设计模式》，有几分共鸣…… [...]

2010年6月星期2 [ 08:41 ]