API 给参数的方式

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

1574 次点击
所在节点    iDev
0 条回复

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/215991

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX