iOS SDK的API接口設計

前言

目前我們所開發(fā)SDK的目的是為了流程簡化的同時,保證數(shù)據(jù)邏輯安全;說到底,我們就是為了要讓流程變簡潔而已。但隨著這些年所開發(fā)出來的SDK,不斷的經(jīng)由客戶的考驗和反饋;越發(fā)覺得開發(fā)SDK的工作前期設計部分非常重要,因為每一版所發(fā)布的SDK,在接口上不能產(chǎn)生太大的變化,為了讓SDK有更好的兼容性,我大概總結了下面的一些方法。

1、提供全能類型的初始化方式

這個方法是我在Objective-c的一些優(yōu)化語言中找到的,因為我們所設計的接口是基于開發(fā)者的角度,所以初始化最好提供全面的初始化方法。

需要盡量提供可能會用到的所有接口,這樣有助于二次開發(fā)(當然這些事情是不可以一步到位的)

- (instancetype) init {
    if (self = [super init]) {
        [self commonInit:6];
    }
    return self;
}

- (instancetype) initWithFrame:(CGRect)frame {
    if (self = [super initWithFrame:frame]) {
        [self commonInit:6];
    }
    return self;
}

-(instancetype)initWithFrame:(CGRect)frame withCount:(int)index{
    self = [super initWithFrame:frame];
    if (self) {
        [self commonInit:index];
    }
    return self;
}

-(instancetype)initWithFrame:(CGRect)frame withCount:(int)index withType:(int)type{
    self = [super initWithFrame:frame];
    if (self) {
        [self commonInt:index with:type];
    }
    return self;
}

2、對象多使用不可變對象

這個是需要看情況而定的,但是對于封裝的類對象,尤其是用于數(shù)據(jù)操作類的,建議盡量創(chuàng)建使用不可變的對象,如果想支持可操作的屬性,可以提供方法來實現(xiàn)修改屬性。

3、使用前綴命名來避免沖突

在使用到更多的類庫以后,就更容易出現(xiàn)名字相同的沖突,尤其是在一些功能性相仿的類,我們之前寫過的DV12的類庫和DFUnit還有最新的DV16的庫就存在過沖突,通常這類沖突在編譯的時候就能檢索出來。

為了避免這種情況,我們可以通過以下的方法來實現(xiàn):

  • 命名的引申義:通過類的功能可以使用駝峰法來命名,但功能總有相似性,于是我們可以使用公司前綴或者簡稱等來命名類以及類方法
  • 第三方庫的引用:對于我們引用的第三方庫的引用,我們通常也能發(fā)現(xiàn)他們具備了自己獨特的類命名方式,而這個時候,我們要做的就是保留他們原有的名字,這不僅僅是避免命名沖突的問題,更多的是對原作者的尊重。
  • 為私有類提供前綴:對于私有不開放的類,我們也可以通過前綴的方式來做區(qū)分,這樣有利于我們在發(fā)布或者打包的時候有效區(qū)分那些是私有的,那些是應該公布出去的。

4、API的層級處理

SDK是應該具備層級架構的,這不僅僅是功能性的體現(xiàn),更是一個庫的核心所在,如果層級架構做得好,那么在二次開發(fā)的時候就能避免很多的問題,邏輯也變得更加的清晰,每個層級關系的嵌套要清晰。

  • 通過類別或功能來進行層級劃分
API的層級處理.png
  • 關于內(nèi)部流程的控制

因為SDK的工作本來就是需要將復雜的流程封裝起來,讓二次調(diào)用的人更簡單、更方便的去使用,但是我們的SDK并不是一次開發(fā)不需要后期維護的,所以為了以后的維護和方便些,我們需要對涉及業(yè)務流程的流程圖和相關邏輯記錄下來,可以通過類內(nèi)部的注釋或者流程圖的方式來記錄。

另外流程也需要獨立性高一點,盡量提高一些簡單流程的復用性,避免整個SDK的庫非常臃腫。

5、錯誤結果的處理

由于SDK是給開發(fā)者二次開發(fā)的,所以log記錄很重要,它可以在第一時間替我們找到問題的發(fā)生點,為此我在SDK中添加了Log打印的等級控制,方便控制打印,還有一個就是需要對這些打印內(nèi)容保存,保存在文件里,當出現(xiàn)問題的時候就可以翻出來查找問題所在了。

錯誤內(nèi)容的反饋還不局限體現(xiàn)在打印上,也可以通過增加錯誤碼列表,來分析定位問題。

6、SDK中消息的傳遞

我們的SDK涉及到較多的數(shù)據(jù)交互,這些是不能局限于庫的內(nèi)部,還要通過協(xié)議上傳給上層,讓二次開發(fā)更加清晰、簡單的獲取到所需的數(shù)據(jù),目前iOS上的消息傳遞大概分為以下幾種,我們可以根據(jù)他們的優(yōu)缺點來進行選擇,當然最好在設計接口的時候能夠考慮到都用上。

傳遞方式 優(yōu)點 缺點
Delegate:代理 數(shù)據(jù)回調(diào)屬于類對象擁有內(nèi)容,數(shù)據(jù)回調(diào)高效可靠,可實現(xiàn)多個函數(shù)來回調(diào)不同數(shù)據(jù)內(nèi)容 局限于當前類,如果要多個類之間傳遞,實現(xiàn)起來的代碼會非常臃腫
block:代碼塊 輕量級的回調(diào),代碼簡潔,邏輯清晰 容易造成循環(huán)引用,臨時性;代碼塊存放在堆棧上,容易造成內(nèi)存泄露
KVO:觀察者 提供了簡單的實現(xiàn)兩個對象同步屬性的方法,能對非我們創(chuàng)建的對象進行狀態(tài)監(jiān)聽,不需要高邊內(nèi)部對象 觀察屬性比較單一,適用的場景較少
NSNotification:通知 整個APP內(nèi)都可以監(jiān)聽這個通知消息,屬于ARC,不用管理內(nèi)存問題 需要配對remove使用,會導致多處接收,多處處理,代碼整體架構處理很混亂

整體的腦圖如下:


iOS SDK的API接口設計.png
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容

  • Swift1> Swift和OC的區(qū)別1.1> Swift沒有地址/指針的概念1.2> 泛型1.3> 類型嚴謹 對...
    cosWriter閱讀 11,136評論 1 32
  • oc語言特性 oc使用動態(tài)綁定的消息結構,在運行時才會檢查對象類型。接收消息后,執(zhí)行代碼,由運行環(huán)境而非編譯器來決...
    勇敢的_心_閱讀 411評論 3 3
  • 郭芳艷 焦點網(wǎng)絡初級五期 堅持原創(chuàng)分享第299天 記得劉老師之前講過一點,覺得特別好,那就是不能想的太...
    冰山藍鷹閱讀 115評論 0 0
  • 小白訓練營學習分享畢業(yè)感悟 大家好,我叫漫步在云端,來自福...
    漫步在云端_85b9閱讀 396評論 1 0