1. 程式人生 > >javascript的api設計原則

javascript的api設計原則

前言

本篇博文來自一次公司內部的前端分享,從多個方面討論了在設計介面時遵循的原則,總共包含了七個大塊。系滷煮自己總結的一些經驗和教訓。本篇博文同時也參考了其他一些文章,相關地址會在後面貼出來。很難做到詳盡充實,如果有好的建議或者不對的地方,還望不吝賜教斧正。

一、介面的流暢性

好的介面是流暢易懂的,他主要體現如下幾個方面:

1.簡單

操作某個元素的css屬性,下面是原生的方法:

document.querySelector('#id').style.color = 'red';

封裝之後

function a(selector, color) {
  document.querySelector(selector).style.color = color
}
a('#a', 'red');

從幾十個字母長長的一行到簡簡單單的一個函式呼叫,體現了api設計原則之一:簡單易用。

2.可閱讀性

a('#a', 'red')是個好函式,幫助我們簡單實用地改變某個元素,但問題來了,如果第一次使用該函式的人來說會比較困惑,a函式是啥函式,沒有人告訴他。開發介面有必要知道一點,大多數人都是懶惰的(包括滷煮自己),從顏色賦值這個函式來說,雖然少寫了程式碼,但是增加了單詞字母的個數,使得它不再好記。每次做這件事情的時候都需要有對映關係: a---->color. 如果是簡單的幾個api倒是無所謂,但是通常一套框架都有幾十甚至上百的api,對映成本增加會使得程式設計師哥哥崩潰。 我們需要的就是使得介面名稱有意義,下面我們改寫一下a函式:

function letSomeElementChangeColor(selector, color) {
  document.querySelectorAll(selector, color).style.color = color; }

letSomeElementChangeColor相對於a來說被賦予了現實語言上的意義,任何人都不需要看說明也能知道它的功能。

3.減少記憶成本

我們剛剛的函式太長了,letSomeElementChangeColor雖然減少了對映成本,有了語言上的意義,但是毫無疑問增加了記憶成本。要知道,包括學霸在內,任何人都不喜歡背單詞。不僅僅在此處,原生獲取dom的api也同樣有這個問題: document.getElementsByClassName

document.getElementsByName; document.querySelectorAll;這些api給人的感覺就是單詞太長了,雖然他給出的意義是很清晰,然而這種做法是建立在犧牲簡易性和簡憶性的基礎上進行的。於是我們又再次改寫這個之前函式

function setColor(selector, color) {
 xxxxxxxxxxxx
} 

在語言意義不做大的變化前提下,縮減函式名稱。使得它易讀易記易用。

4.可延伸

所謂延伸就是指函式的使用像流水一樣按照書寫的順序執行形成執行鏈條:

document.getElementById('id').style.color = 'red';
document.getElementById('id').style.fontSize = '12px';
document.getElementById('id').style.backgourdColor = 'pink';

如果我們需要實現像以上有強關聯性的業務時,用我們之前的之前的方法是再次封裝兩個函式 setFontSize, setbackgroundColor; 然後執行它們 setColor('id', 'red');setFontSiez('id', '12px'); setbackgroundColor('id', 'pink'); 顯然,這樣的做法沒有懶出境界來;id元素每次都需要重新獲取,影響效能,失敗;每次都需要新增新的方法,失敗; 每次還要呼叫這些方法,還是失敗。下面我們將其改寫為可以延伸的函式 首先將獲取id方法封裝成物件,然後再物件的每個方法中返回這個物件:

function getElement(selector) {
  this.style = document.querySelecotrAll(selector).style;
}

getElement.prototype.color = function(color) {
  this.style.color = color;
  return this;
}
getElement.prototype.background = function(bg) {
  this.style.backgroundColor = bg;
  return this;
}
getElement.prototype.fontSize = function(size) {
  this.style.fontSize = size;
  return this;
}

//呼叫
var el = new getElement('#id')
el.color('red').background('pink').fontSize('12px');

簡單、流暢、易讀,它們看起來就像行雲流水一樣,即在程式碼效能上得到了提升優化,又在視覺上悅目。後面我們會在引數裡面講到如何繼續優化。

所以,大家都比較喜歡用jquery的api,雖然一個$符號並不代表任何現實意義,但簡單的符號有利於我們的使用。它體現了以上的多種原則,簡單,易讀,易記,鏈式寫法,多參處理。

nightmare:

document.getElementById('id').style.color = 'red';
document.getElementById('id').style.fontSize = '12px';
document.getElementById('id').style.backgourdColor = 'pink';

dream:

$('id').css({color:'red', fontSize:'12px', backgroundColor:'pink'})

二、一致性

1.介面的一致性

相關的介面保持一致的風格,一整套 API 如果傳遞一種熟悉和舒適的感覺,會大大減輕開發者對新工具的適應性。 命名這點事:既要短,又要自描述,最重要的是保持一致性 “在電腦科學界只有兩件頭疼的事:快取失效和命名問題” — Phil Karlton 選擇一個你喜歡的措辭,然後持續使用。選擇一種風格,然後保持這種風格。

Nightmare:

setColor,
letBackGround
changefontSize
makedisplay

dream:

setColor;
setBackground;
setFontSize
set.........

儘量地保持程式碼風格和命名風格,使別人讀你的程式碼像是閱讀同一個人寫的文章一樣。

三、引數的處理

1.引數的型別

判斷引數的型別為你的程式提供穩定的保障

//我們規定,color接受字串型別
function setColor(color) {
  if(typeof color !== 'string') return;
dosomething
}

2.使用json方式傳參

使用json的方式傳值很多好處,它可以給引數命名,可以忽略引數的具體位置,可以給引數預設值等等 比如下面這種糟糕的情況:

function fn(param1, param2...............paramN)

你必須對應地把每一個引數按照順序傳入,否則你的方法就會偏離你預期去執行,正確的方法是下面的做法。

function fn(json) {
//為必須的引數設定預設值
   var default = extend({
	param: 'default',
	param1: 'default'
	......
   },json)
}

這段函式程式碼,即便你不傳任何引數進來,他也會預期執行。因為在宣告的時候,你會根據具體的業務預先決定引數的預設值。

四、可擴充套件性

軟體設計最重要的原則之一:永遠不修改介面,而是去擴充套件它!可擴充套件性同時會要求介面的職責單一,多職責的介面很難擴充套件。 舉個栗子:

//需要同時改變某個元素的字型和背景 
// Nightmare:
function set(selector, color) {
  document.querySelectroAll(selector).style.color = color;
  document.querySelectroAll(selector).style.backgroundColor = color;
}

//無法擴充套件改函式,如果需要再次改變字型的大小的話,只能修改此函式,在函式後面填加改變字型大小的程式碼

//Dream
function set(selector, color) {
  var el = document.querySelectroAll(selector);
  el.style.color = color;
  el.style.backgroundColor = color;
  return el;
}

//需要設定字型、背景顏色和大小
function setAgain (selector, color, px) {
  var el = set(selector, color)
  el.style.fontSize = px;
  return el;
}

以上只是簡單的新增顏色,業務複雜而程式碼又不是你寫的時候,你就必須去閱讀之前的程式碼再修改它,顯然是不符合開放-封閉原則的。修改後的function是返回了元素物件,使得下次需要改變時再次得到返回值做處理。

2.this的運用

可擴充套件性還包括對this的以及call和apply方法的靈活運用:

function sayBonjour() {
  alert(this.a)
}

obj.a = 1;
obj.say = sayBonjour;
obj.say();//1
//or
sayBonjour.call||apply(obj);//1

五、對錯誤的處理

1.預見錯誤

可以用 型別檢測 typeof 或者try...catch。 typeof 會強制檢測物件不丟擲錯誤,對於未定義的變數尤其有用。

2.丟擲錯誤

大多數開發者不希望出錯了還需要自己去找帶對應得程式碼,最好方式是直接在console中輸出,告訴使用者發生了什麼事情。我們可以用到瀏覽器為我們提供的api輸出這些資訊:console.log/warn/error。你還可以為自己的程式留些後路: try...catch。

function error (a) {
  if(typeof a !== 'string') {
    console.error('param a must be type of string')
  }
}

function error() {
  try {
    // some code excucete here maybe throw wrong 
  }catch(ex) {
    console.wran(ex);
  }
}

六、可預見性

可預見性味程式介面提供健壯性,為保證你的程式碼順利執行,必須為它考慮到非正常預期的情況。我們看下不可以預見的程式碼和可預見的程式碼的區別用之前的setColor

//nighware
function set(selector, color) {
  document.getElementById(selector).style.color = color;
}

//dream
zepto.init = function(selector, context) {
  var dom
  // If nothing given, return an empty Zepto collection
  if (!selector) return zepto.Z()
  // Optimize for string selectors
  else if (typeof selector == 'string') {
    selector = selector.trim()
    // If it's a html fragment, create nodes from it
    // Note: In both Chrome 21 and Firefox 15, DOM error 12
    // is thrown if the fragment doesn't begin with <
    if (selector[0] == '<' && fragmentRE.test(selector))
      dom = zepto.fragment(selector, RegExp.$1, context), selector = null
    // If there's a context, create a collection on that context first, and select
    // nodes from there
    else if (context !== undefined) return $(context).find(selector)
    // If it's a CSS selector, use it to select nodes.
    else dom = zepto.qsa(document, selector)
  }
  // If a function is given, call it when the DOM is ready
  else if (isFunction(selector)) return $(document).ready(selector)
  // If a Zepto collection is given, just return it
  else if (zepto.isZ(selector)) return selector
  else {
    // normalize array if an array of nodes is given
    if (isArray(selector)) dom = compact(selector)
    // Wrap DOM nodes.
    else if (isObject(selector))
      dom = [selector], selector = null
    // If it's a html fragment, create nodes from it
    else if (fragmentRE.test(selector))
      dom = zepto.fragment(selector.trim(), RegExp.$1, context), selector = null
    // If there's a context, create a collection on that context first, and select
    // nodes from there
    else if (context !== undefined) return $(context).find(selector)
    // And last but no least, if it's a CSS selector, use it to select nodes.
    else dom = zepto.qsa(document, selector)
  }
  // create a new Zepto collection from the nodes found
  return zepto.Z(dom, selector)
}

以上是zepto的原始碼,可以看見,作者在預見傳入的引數時做了很多的處理。其實可預見性是為程式提供了若干的入口,無非是一些邏輯判斷而已。zepto在這裡使用了很多的是非判斷,這樣做的好處當然是程式碼比之前更健壯,但同時導致了程式碼的冗長,不適合閱讀。總之,可預見性真正需要你做的事多寫一些對位置實物的引數。把外部的檢測改為內部檢測。是的使用的人用起來舒心放心開心。吶!做人嘛最重要的就是海森啦。

七、註釋和文件的可讀性

一個最好的介面是不需要文件我們也會使用它,但是往往介面量一多和業務增加,介面使用起來也會有些費勁。所以介面文件和註釋是需要認真書寫的。註釋遵循簡單扼要地原則,給多年後的自己也給後來者看:

//註釋介面,為了演示PPT用
function commentary() {
  //如果你定義一個沒有字面意義的變數時,最好為它寫上註釋:a:沒用的變數,可以刪除
  var a;

  //在關鍵和有歧義的地方寫上註釋,猶如畫龍點睛:路由到hash介面後將所有的資料清空結束函式
  return go.Navigate('hash', function(){
    data.clear();
  });
}

最後

推薦markdown語法書寫API文件,github御用文件編寫語法。簡單、快速,程式碼高亮、話不多說上圖

滷煮在此也推薦幾個線上編輯的網站。諸君可自行前往練習使用。

參考博文

相關推薦

面向對象的七個設計原則

必須 支持 xtra 帶來 類的繼承 沒有 方法 抽象 產生 一、單一職責原則 一個類,最好只做一件事,只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則上的引申,將職責定義為引起變化的原因,以提高內聚性來減少引起變化的原因。職責過多,可能引起它變化的

面向對象設計原則

封裝 int 變化 事物 倒置 訪問權限 抽象類 帶來 理解 一、單一職責原則: 全稱:“Single-Responsibility Principle” 說明:就一個類而言,應該只專註於做一件事和僅有一個引起它變化的原因。所謂職責,我們可以理解他為功能,就是設計的這個類功

四個基礎的UI設計原則

ui設計UI設計師想要減少改稿次數,拒絕產品經理“加一道光”的需求,首先要學會不靠感覺做設計。今天這篇文章從設計原則的重要性談起,總結了四個UI的基本設計原則,讓你每一個元素界面都有理有據,適合剛入門的設計師,一起來學習ui設計吧。  圖形設計大師Paul Rand(保羅·蘭德)曾經說過:  “設計絕不是簡單

【遊戲開發】淺談遊戲開發中常見的設計原則

依賴關系 unity 說過 srp des log gof https 類繼承   俗話說得好:“設計模式,常讀常新~”。的確,每讀一遍設計模式都會有些新的體會和收獲。馬三不才,才讀了兩遍設計模式(還有一遍是在學校學的),屬於菜鳥級別的。這次準備把閱

java七大設計原則

一句話 新的 多個 構造 ron 最終 調用 抽象 條件 1.開閉原則(Open Close Principle) 定義:一個軟件實體如類、模塊和函數應該對擴展開放,對修改關閉。 開放-封閉原則的意思就是說,你設計的時候,時刻要考慮,盡量讓這個類是足夠好,寫好了就不

《轉》面向對象類設計原則

href 編程 相等 tro 設計時 對象 函數參數 種子 代碼 面向對象類的設計原則 1 SRP(單一職責原則) 這個原則看起來很簡單,就是說一個類只能承擔一個職責。 但這裏有一個關鍵:“職責”是如何理解的? 按照漢語的理解,職責其實分為兩

JavaScript 的 API 設計原則

rst 執行 creat 錯誤 htm ora 大小 閱讀 fontsize 前言 本篇博文來自一次公司內部的前端分享,從多個方面討論了在設計接口時的原則,總共包含了七個大塊。系鹵煮自己總結的一些經驗教訓。同時也參考了一些文章,地址會在後面貼出來。很難做到詳盡充實,如果

解讀設計原則

場景 ood 子類 寫代碼 oschina tro 也會 客戶端 選擇 概述 設計原則就一本菜譜,告訴我們一道美味的菜應該是什麽樣的,或者說需要具備什麽。但是又沒有一個固化或可測量的標準。寫代碼就和烹飪一樣,只有當自己品嘗以後才知其味。 1 開閉原則 定義: 開閉原則(Op

面向對象的七種基本設計原則

思想 reg end 開放 -s 通過 接口隔離原則 類的方法 bsp 面向對象的7種基本設計原則: 裏氏替換原則單一職責原則依賴倒置原則接口隔離原則開放關閉原則迪米特法則(最少知道原則)合成復用原則 面向對象的3個基本要素:封裝、繼承、多態 1.裏氏替換原則(Liskov

Java設計原則—接口隔離原則(轉)

java設計 關系 提高 接口隔離原則 不能 設計時 而不是 根據 結構 接口隔離原則 Interface Segregation Principle 定義: 客戶端不應該依賴它不需要的接口 類間的依賴關系應該建立在最小的接口上 我們可以把這兩個定義概括為一句話:

面向對象設計原則之四:依賴倒置原則

ron 通過 發生 需要 系統 面向對象設計 啟動 模塊 == 依賴倒置原則 所謂依賴倒置原則(Dependence Inversion Principle )就是要依賴於抽象,不要依賴於具體。簡單的說就是對抽象進行編程,不要對實現進行編程,這樣就降低了客戶與實

系統設計原則

特定 備份 壓縮 支持 交換 產品 system 行動 標準 以技術先進、系統實用、結構合理、產品主流、低成本、低維護量作為基本建設原則,規劃系統的整體構架。 先進性: 在產品設計上,整個系統軟硬件設備的設計符合高新技術的潮流,媒體數字化、壓縮、解壓、傳輸等關鍵設備均處於國

面向對象五大設計原則

gof 黃河 文件 容易 style 繼承 單一職責原則 原來 幫助 以前一直認為程序中的類有使用到封裝繼承多態就是面向對象設計,其實不然 封裝,繼承,多態只是面向對象的三大特性,但是在設計程序的時候並不是說類的結構使用到了(或是體現出了)這三個特性就是面向對象, 其實

SoC嵌入式軟件架構設計之三:代碼分塊(Bank)設計原則

post 介紹 讀寫 cor 層次 clas rom bank 分配 上一節講述了在沒有MMU的CPU(如80251、MIPS M控制器系列、ARM cortex m系列)上實現虛擬內存管理的集成硬件設計方法。新設計的內存管理管理單元要實現虛擬內存管理還須要

零散知識點(面向對象七大設計原則,jdbc--BaseDao,jsp九大內置對象。四個作用域)

面向 -c 隔離 logs 基礎上 面向對象 通過 介紹 family 面向對象七大設計原則: 1、開閉原則(OCP:Open-Closed Principle)2、裏氏替換原則(LSP:Liskov Substitution Principle) 3、單一職責原則(SR

七大設計原則之迪米特法則

權限 and void com 復雜 ron head 使用 logs 定義   迪米特法則(Law of Demeter,LoD)也稱為最少知識原則(Least Knowledge Principle,LKP)。   一個對象應該對其他對象有最少的了解。通俗地講,一個

設計原則之宜家效應:如何讓人們愛上你的產品

產品設計 以下內容由Mockplus團隊翻譯整理,僅供學習交流,Mockplus是更快更簡單的原型設計工具。 宜家效應是一種能夠在很大程度上影響產品的成果和感知價值的認知偏差。 人們傾向於高度重視他們自己創造的產品部分。 因此,這種認知偏差被稱作宜家效應。 它來自於瑞典家具零售商,因需要用

面向對象設計原則一:單一職責原則(SRP)

能夠 實現 update 之間 關註 linq 好處 相互 並且 單一職責原則(SRP) 定義:系統中的每一個類都應該只有一個職責。 好處:高內聚、低耦合。 解釋說明: 單一職責也就是說我們應該讓一個類或一個對象只做一件事情,每個類所要關註的就是自己要完成的

面向對象設計原則二:開閉原則(OCP)

name 返回 展開 打開 設計原則 data turn acl int 開閉原則(OCP)定義:對擴展開發,對修改關閉。好處: 適應性和靈活性。 穩定性和延續性。 可復用性與可維護性。 解釋說明:開閉原則指的是兩方面:對功能擴展開發,對修改進

面向對象設計原則四:依賴倒置原則

設計原則 面向 dip 定性 穩定 要求 這樣的 覆蓋 通過 依賴倒置原則(DIP) 定義:高層模塊不應該依賴底層模塊,兩者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。   好處:穩定性、可維護性、可擴展性。  概述:DI就是依賴倒置的意思,也可稱