问题导向，用更少做更多。
给API传参数，和回调处理，是每个业务工程师在网络模块封装好的前提下，依然必须要做的事情。
传参，有几种方式，其中一种是这样的：
[[RegisterApi alloc] initWithUsername:@"username" password:@"password"]
这种方式的好处是，通过方法名给参数，可以做最简单的类型检查。
另一种是这样的：
- (NSDictionary *)paramsForApi:(APIBaseManager *)manager
{
if ([manager isKindOfClass:[XXX class]])
{
return @{
@"username":@"ABC"
@"password":@"123"
};
}
return nil;
}
这种方式的好处是，可以在一个方法里给不同的API传参数。
最近项目中就有这样的需求，同一个API，通过不同的参数获取结构相同的不同数据。
如果是共用一个ViewController类，第二种方式就有明显优势。
当然，第一种方式，也可以通过包一层，模仿第二种方式。
[[RegisterApi alloc] initWithUsername:params[@"username"] password:params[@"password"]];
后记(下面以聊家常为主，没时间没兴趣的朋友请直接忽略)：
今天我在思考客户专家、技术专家、问题专家的路径选择。
1､研究一个客户的所有问题
2､研究一个技术的所有问题
3､研究一个问题的所有技术
我很确定，自己对客户专家没兴趣。
选择的问题在于，是往技术专家的方向走，还是往问题专家的方向走。
我本能更倾向于技术专家方向，在一个技术方向不断地积累知识、技能、经验。
然后，粉丝群里的一位朋友问了我一个问题：你怎么看待搞iOS XXX的人？
这个问题问得特别好。
我可以非常确定自己对 XXX不感兴趣。
那么问题来了，如果我对iOS的XXX或YYY不感兴趣，我怎么成为iOS技术专家呢？
于是，我很确定，我当不了技术专家。
我终于发现，自己只对有限的一些问题感兴趣。
所以，唯一的希望是努力成为问题专家。
@xiaotie 兄是问题专家。于是，我又再倒回去，看了他的几篇文章：
只学一点点：我的技术学习策略
http://www.cnblogs.com/xiaotie/archive/2011/12/10/2283384.html
裘千丈还是裘三尺——用挖矿的比喻说平台与门槛
http://www.cnblogs.com/xiaotie/archive/2012/11/28/2792665.html
一个回复
http://ourcoders.com/thread/show/6615/
@xiaotie 兄除了专注于一类问题以外，还有一个突色，就是在解决问题的时候尽量用最少的技术去实现。
比如：
假设一个问题，可分为3部分。
1 2 3
一般，我们会被建议，不同的部分用最适合的技术去实现：
A B C
这种做法，看起来非常合理，缺点是你得学不少的不同的技术。
@xiaotie 兄的做法是：
A A+ A++
好处是只需要专注于一个技术，问题自然是可能A+的不如B做得好，A++的不如C做得好。
而目前业界的常见做法是这样：
D(A) E(B) F(C)
这种把现有技术再包一层的做法，将会非常累人，因为要学的技术层出不穷，越来越多。
@xiaotie 兄还计划进一步做成这样子：
a+ a++ a+++
这样可以进一步缩减更多的技术范围。挑战自然是，如果要从头去实现，需要对实现原理有足够的研究。
