API 给参数的方式

[cralison]

问题导向，用更少做更多。

给 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+++
这样可以进一步缩减更多的技术范围。挑战自然是，如果要从头去实现，需要对实现原理有足够的研究。