最近在用同事的庫(kù)做二次開(kāi)發(fā)，新的工程是打算用Swift來(lái)寫(xiě)实夹，結(jié)果我發(fā)在處理一個(gè)數(shù)據(jù)的回調(diào)的時(shí)候橄浓，只要去讀一下那個(gè)數(shù)據(jù)就會(huì)出錯(cuò)。我一度懷疑我可能學(xué)的假Swift了亮航，怎么處理個(gè)普通的delegate回調(diào)都不行了呢荸实？！
當(dāng)我對(duì)數(shù)據(jù)進(jìn)行追蹤的時(shí)候缴淋，我發(fā)現(xiàn)錯(cuò)誤來(lái)自于庫(kù)里面准给，它通過(guò)一個(gè)回調(diào)，回調(diào)了不同的數(shù)據(jù)內(nèi)容重抖，導(dǎo)致我在讀的時(shí)候露氮，出現(xiàn)數(shù)據(jù)類型不匹配的錯(cuò)誤，具體如下：
@protocol ManagerDelegate <NSObject>
@optional
/**
@param array 設(shè)備數(shù)組
@param status 狀態(tài)
*/
-(void)onManagerPeripherals:(NSArray<Entity*> *)array
updateStatus:(BLEStatus)status;
/////////////////////////////////////////////
這里使用的是一種可選的回調(diào)仇哆，主要想用來(lái)回調(diào)數(shù)組內(nèi)容為Entity的數(shù)據(jù)內(nèi)容
然后我進(jìn)入回調(diào)內(nèi)容那里一看沦辙，事情大條了
-(void)notePeripheralChanged:(NSNotification*)note{
NSString *name = note.name;
NSArray *peripherals = [NSArray new];
BLEStatus status = BLEStatusUnknown;
//分別處理不同命令
if ([name isEqual:kUI_BLE_FOUND])
{
status = JL_BLEStatusFound;
peripherals = note.object; // 這里傳回來(lái)的是一組[Entity] 內(nèi)容
}
else if ([name isEqual:kUI_BLE_PAIRED])
{
status = BLEStatusPaired;
Entity *entity = note.object;
if (entity) peripherals = @[entity.mPeripheral]; // 但是這里的不是！６锾蕖Ｓ脱丁！
}
if ([_managerDelegate respondsToSelector:@selector(onManagerPeripherals:updateStatus:)]) {
[_managerDelegate onManagerPeripherals:peripherals updateStatus:status];
}
}
這樣的回調(diào)在Objective-c中是沒(méi)有問(wèn)題的延欠，只要針對(duì)不同的Status來(lái)對(duì)應(yīng)讀取內(nèi)容就可以了陌兑，但是這樣的寫(xiě)法在Swift中卻是非常致命的。
由此可見(jiàn)Swift的嚴(yán)謹(jǐn)性還是高于Objective-c的由捎。
而且兔综，我個(gè)人也非常不建議使用這樣的寫(xiě)法，這樣會(huì)導(dǎo)致在外面調(diào)用這些方法的人難以理解回調(diào)的數(shù)據(jù)類型狞玛。
在平時(shí)我們使用這種回調(diào)方法的時(shí)候软驰，要么就不確定類型，讓盡可能多的數(shù)據(jù)從一個(gè)接口回調(diào)到上層心肪，再分流锭亏。要么就制定只回調(diào)一種類型的數(shù)據(jù)，那樣才能寫(xiě)出優(yōu)秀的代碼硬鞍。
