問題導(dǎo)向，用更少做更多。
給API傳參數(shù)，和回調(diào)處理，是每個(gè)業(yè)務(wù)工程師在網(wǎng)絡(luò)模塊封裝好的前提下，依然必須要做的事情。
傳參，有幾種方式，其中一種是這樣的：
[[RegisterApi alloc] initWithUsername:@"username" password:@"password"]
這種方式的好處是，通過方法名給參數(shù)，可以做最簡單的類型檢查。
另一種是這樣的：
- (NSDictionary *)paramsForApi:(APIBaseManager *)manager
{
if ([manager isKindOfClass:[XXX class]])
{
return @{
@"username":@"ABC"
@"password":@"123"
};
}
return nil;
}
這種方式的好處是，可以在一個(gè)方法里給不同的API傳參數(shù)。
最近項(xiàng)目中就有這樣的需求，同一個(gè)API，通過不同的參數(shù)獲取結(jié)構(gòu)相同的不同數(shù)據(jù)。
如果是共用一個(gè)ViewController類，第二種方式就有明顯優(yōu)勢。
當(dāng)然，第一種方式，也可以通過包一層，模仿第二種方式。
[[RegisterApi alloc] initWithUsername:params[@"username"] password:params[@"password"]];
后記(下面以聊家常為主，沒時(shí)間沒興趣的朋友請直接忽略)：
今天我在思考客戶專家、技術(shù)專家、問題專家的路徑選擇。
1?研究一個(gè)客戶的所有問題
2?研究一個(gè)技術(shù)的所有問題
3?研究一個(gè)問題的所有技術(shù)
我很確定，自己對客戶專家沒興趣。
選擇的問題在于，是往技術(shù)專家的方向走，還是往問題專家的方向走。
我本能更傾向于技術(shù)專家方向，在一個(gè)技術(shù)方向不斷地積累知識(shí)、技能、經(jīng)驗(yàn)。
然后，粉絲群里的一位朋友問了我一個(gè)問題：你怎么看待搞iOS XXX的人？
這個(gè)問題問得特別好。
我可以非常確定自己對 XXX不感興趣。
那么問題來了，如果我對iOS的XXX或YYY不感興趣，我怎么成為iOS技術(shù)專家呢？
于是，我很確定，我當(dāng)不了技術(shù)專家。
我終于發(fā)現(xiàn)，自己只對有限的一些問題感興趣。
所以，唯一的希望是努力成為問題專家。
@xiaotie 兄是問題專家。于是，我又再倒回去，看了他的幾篇文章：
只學(xué)一點(diǎn)點(diǎn)：我的技術(shù)學(xué)習(xí)策略
http://www.cnblogs.com/xiaotie/archive/2011/12/10/2283384.html
裘千丈還是裘三尺——用挖礦的比喻說平臺(tái)與門檻
http://www.cnblogs.com/xiaotie/archive/2012/11/28/2792665.html
一個(gè)回復(fù)
http://ourcoders.com/thread/show/6615/
@xiaotie 兄除了專注于一類問題以外，還有一個(gè)突色，就是在解決問題的時(shí)候盡量用最少的技術(shù)去實(shí)現(xiàn)。
比如：
假設(shè)一個(gè)問題，可分為3部分。
1 2 3
一般，我們會(huì)被建議，不同的部分用最適合的技術(shù)去實(shí)現(xiàn)：
A B C
這種做法，看起來非常合理，缺點(diǎn)是你得學(xué)不少的不同的技術(shù)。
@xiaotie 兄的做法是：
A A+ A++
好處是只需要專注于一個(gè)技術(shù)，問題自然是可能A+的不如B做得好，A++的不如C做得好。
而目前業(yè)界的常見做法是這樣：
D(A) E(B) F(C)
這種把現(xiàn)有技術(shù)再包一層的做法，將會(huì)非常累人，因?yàn)橐獙W(xué)的技術(shù)層出不窮，越來越多。
@xiaotie 兄還計(jì)劃進(jìn)一步做成這樣子：
a+ a++ a+++
這樣可以進(jìn)一步縮減更多的技術(shù)范圍。挑戰(zhàn)自然是，如果要從頭去實(shí)現(xiàn)，需要對實(shí)現(xiàn)原理有足夠的研究。
