Artsy 工程师总结的一些 Cocoa 开发设计误区

<b>本文讲的是Artsy 工程师总结的一些 Cocoa 开发设计误区，</b>

<b></b>

在开发 Artsy 这款 iOS app 的时候，我们尝试了一些设计模式。现在我想要谈谈现在我们有的和已经被移除的设计模式。我不会面面俱到，毕竟已经历了那么长时间，有那么多人参与过。我想从更高的层面去审视，关注那些总体上更重要的东西。

很重要的一点需要先声明下，我不相信有完美的代码，或者说我喜欢重写代码。我们可以发现一个坏的模式而什么都不做。毕竟我们有 app 需要完成，而不可能纯粹为了技术，追求更完美的代码库。

大量 Energy 的初始代码库依靠 <code>NSNotification</code> 在应用程序内传递信息。这些通知用于用户设置调整，下载状态更新，授权与相应的错误状态，以及一些 app 特性。这些 Energy 代码太过于依赖这些全局通知进行交流，而鲜有尝试去窥探对象之间的关系。

使用 <code>NSNotification</code> 最大的弊端在于容易使得开发者变懒。它允许你不去深究对象之间的关系，假装它们是松耦合的。而实际当他们是耦合的时候，却通过字符串形式的通知传递消息。

@implementation ARAddToAlbumViewController

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

{

if (indexPath.row &lt; [self.albums count]) {

Album *selectedAlbum = ((Album *)self.albums[indexPath.row]);

ARTickedTableViewCell *cell = (ARTickedTableViewCell *)[self.tableView cellForRowAtIndexPath:indexPath];

if ([cell isSelected]) {

[ARAnalytics event:ARRemoveFromAlbumEvent withProperties:@{

@"artworks" : @(self.artworks.count),

@"from" : [ARNavigationController pageID]

}];

[...]

@implementation ARAppDelegate (Analytics)

- (void)setupAnalytics

ArtsyKeys *keys = [[ArtsyKeys alloc] init];

[ARAnalytics setupWithAnalytics: @{ [...] } configuration:

@{

ARAnalyticsTrackedEvents:

@[

ARAnalyticsClass: ARAddToAlbumViewController.class,

ARAnalyticsDetails: @[

ARAnalyticsEventName: ARRemoveFromAlbumEvent,

ARAnalyticsSelectorName: NSStringFromSelector(@selector(tableView: didSelectRowAtIndexPath:)),

ARAnalyticsProperties: ^NSDictionary*(ARAddToAlbumViewController *controller, NSArray *_) {

return @{

@"artworks" : @(controller.artworks.count),

@"from" : [ARNavigationController pageID],

};

},

]

很长一段时间，我更喜欢基于类的 API 美学。比如使用类方法而不是实例方法。我一直是这么做。然而，一旦你开始给项目添加测试，这就会产生一些问题。

举一个来自 Energy 的好例子，我们的根视图控制器 <code>ARTopViewController</code> 过去常常控制自己的工具栏项目（toolbar items）。经过四年的时间这变得难以管理，在视图控制器有大量的额外代码。通过抽取控制工具栏项目（toolbar items）的实现细节到他们自己的类，从而让 <code>ARTopViewController</code> 展示自己想要做的而不是怎么做的。

视图控制器里允许小伙伴选择各自想要传递给对象的细节，然后生成 HTML，这部分最终变得具有很强的代码异味，让你想要重写。我发现想要给类的行为写个简单的测试是很困难的。一开始我要模拟（mock） email 组件，然后检查我所调用的方法。这感觉是错的，因为你不应该模拟（mock）你自己的类。类提供了重要的功能，对于如何改进这部分代码，我想了很久。

设计模式有很多，而它们全都来源于权衡。随着时间的推移，我们对于什么是“好的代码”的标准会变，这是好事。重要的是，作为开发者，我们明白，能改变我们思想的，才是我们工具链中最必不可少的技能之一。这意味着你要走出自己原本的认知范围，乐于接受那些外来的信息，或许，你会从中获得一些很不错的点子。对于创造应用持有热情是好的，不过我想，最好的程序员选择实用主义而不是理想主义。

<b>原文发布时间为：2016年01月07日</b>

<b>本文来自云栖社区合作伙伴掘金，了解相关信息可以关注掘金网站。</b>