c-API设计问题,两对函数名

问题描述

API设计问题,两对函数名

假如现在我要在jquery基础上,自己封装一个小框架。
需求如下:可以在UI组件的show动作之前,添加一些回调函数,也可以show动作之后,添加一些回调函数
现在我给UI组件添加了两个函数:

 widget.on(showOrOtherAction,func)
widget.before(showOrOtherAction,func)

这样看起来不错了,两个函数,都是用来给自定义事件添加回调函数。一个是会在Action发生之前触发,一个是会在其后触发。
但是后面又有需求,希望能给这些回调函数解绑。
这下只能另外加两个函数,但是麻烦是,on对应的是off,before对应啥呢,想不到叫啥好?
注意,这个问题是问API的设计,已经API命名的,不是问怎么实现代码

解决方案

before对应after。
一些常用的相关词汇,你可以参考:
init -> 初始化
start/begin -> 开始
xxxing ->正在xxx
xxxed ->xxx完成
after/xxxfinished -> 之后,xxx完成
pre -> 之前
next -> 下一个
load -> 加载
unload -> 卸载
unxxx -> 撤销xxx动作

解决方案二:

不用on before来做函数名而是用addobserver removeobserver
然后参数来标示on before等动作

时间: 2024-08-04 01:17:03

c-API设计问题,两对函数名的相关文章

iOS私有API(二) UIGestureRecognizerDelegate的两个函数

UIGestureRecognizerDelegate有两个没公开的函数,只要重载了就会被调用. 即所有的UIGestureRecognizer子类.delegate = someInstance; 经过set以后,只要这个delegate实例里有这两个函数,就会被调用进入.经过验证,这两个api是可以通过apple审查上app store的. - (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer canBePrev

浅谈关于JavaScript API设计的一些建议和准则

  这篇文章主要介绍了浅谈关于JavaScript API设计的一些建议和准则,文中列举了许多知名的JS API进行辅助说明,极力推荐!需要的朋友可以参考下 设计是一个很普遍的概念,一般是可以理解为为即将做的某件事先形成一个计划或框架. (牛津英语词典)中,设计是一种将艺术,体系,硬件或者更多的东西编织到一块的主线.软件设计,特别是作为软件设计的次类的API设计,也是一样的.但是API设计常常很少关注软件发展,因为为其他程序员写代码的重要性要次于应用UI设计和最终用户体验. 但是API设计,作为

jQuery最出色的是 API 设计

jQuery 将马上发布 1.4 正式版,代码也从 googlecode 上迁移到了 github. jQuery 是我接触的第一个 JS 类库,俗话说初恋总是让人难以忘记.一年以前,这种难以忘记仅仅是一种纯感觉,说不出来具体原因.前几天重新看了一遍 github 上的源码.从纯功能上说,jQuery 并没有特别出色的地方.究竟是什么让我如此恋恋不舍呢? 昨天搭建 taskspeed, 检查 jQuery 的测试代码时,突然明晓了一个也许大家都已知道的秘密: jQuery 最出色最让人恋恋不舍的

从达标到卓越 —— API 设计之道

新技术层出不穷,长江后浪推前浪.在浪潮褪去后,能留下来的,是一些经典的设计思想. 在前端界,以前有远近闻名的 jQuery,近来有声名鹊起的 Vue.js.这两者叫好又叫座的原因固然有很多,但是其中有一个共同特质不可忽视,那便是它们的 API 设计 非常优雅. 因此这次我想来谈个大课题 -- API 设计之道. 讨论内容的定义域 本文并不是<jQuery API 赏析>,当我们谈论 API 的设计时,不只局限于讨论「某个框架应该如何设计暴露出来的方法」.作为程序世界分治复杂逻辑的基本协作手段,

JavaScript API 设计原则

好的 API 设计:在自描述的同时,达到抽象的目标. 设计良好的 API ,开发者可以快速上手,没必要经常抱着手册和文档,也没必要频繁光顾技术支持社区. 流畅的接口 方法链:流畅易读,更易理解 //常见的 API 调用方式:改变一些颜色,添加事件监听  var elem = document.getElementById("foobar");  elem.style.background = "red";  elem.style.color = "gree

浅谈关于JavaScript API设计的一些建议和准则_基础知识

 设计是一个很普遍的概念,一般是可以理解为为即将做的某件事先形成一个计划或框架. (牛津英语词典)中,设计是一种将艺术,体系,硬件或者更多的东西编织到一块的主线.软件设计,特别是作为软件设计的次类的API设计,也是一样的.但是API设计常常很少关注软件发展,因为为其他程序员写代码的重要性要次于应用UI设计和最终用户体验. 但是API设计,作为我们自己写的库中提供的公共接口,能够向调用我们代码的开发者表现出我们库的一些特点和功能,所以API设计和UI设计一样重要.事实上,两者都是为应用可以提供更好

enode框架入门:Command Service API设计思路

上一篇文章,介绍了enode框架的物理部署思路.本文我们再简单分析一下Command Service的API设计: Command Service在enode框架中的地位非常重要,用户使用enode框架的主入口就是command service .UI层如controller会通过发送command给command service,然后框架就开始处理该command.不然看出, command service有可能会被高并发的访问.那么command service该提供什么样的API呢? 首先

我所理解的RESTful Web API [设计篇]

<我所理解的RESTful Web API [Web标准篇]>Web服务已经成为了异质系统之间的互联与集成的主要手段,在过去一段不短的时间里,Web服务几乎清一水地采用SOAP来构建.构建REST风格的Web服务是最近两三年风行的潮流,所以很多人以为REST是一个事物.而事实却是:REST自其诞生之日起到现在(2014年)已经有14年了,它为什么叫这么一个"奇怪"的名字呢? 目录 一.为什么叫这个"奇怪"的名字?二.采用URI标识资源 二.采用URI标识

开发那点事系列三 - 由XML解析引起的API设计思考

      谈起XML解析,大家可能第一反应是DOM,SAX模型.没错,在Java领域,无论是Dom4j, Jdom,还是XOM,其底层都会依赖具体的解析器引擎(Crimson or Xerces)去做事,具体的实现后面会有文章陆续探究.今天写这篇文章的主要目的是想和大家分享自己使用Java SE6的StAX API的一些感受,尤其是对其API的设计理念的一个思考,没多少文字,主要是一些启发性的东东.当然,在你继续浏览之前,希望能熟练掌握以下类库,有助于更好的和我产生共鸣,哈哈:       S