代理方法:

Rule 24: 通知关联的 userInfo 要尽量详细

尽量为通知提供有用的信息。记住：通知接收方（很）可能与你组件里面的代理方法或者数据源链完全无关。

你要想想到底哪些信息会有用，并提供相应的信息。至少，你必需确保代理方法的所有参数都包含在 userInfo 对象里。

代理方法:

Rule 25: 最终测试

最终有些事我们已经知道了. 软件工程和敬业精神的第101条: 确保它真地有效.

是否用正式TDD测试取决于你，但是测试是不可缺少的。每个可选的委托方法。每一个发布的通知。定制的每一个点，在每一个可能的组合。组件提供了一千个微妙的问题的机会。

可能有一些缺陷。找到他们，先解决这些问题。如果你的时间推后，切功能，而不是调试。你要受的苦没有出货的错误。

最后的思考

我制定上述的规则是通过我自己这几年在创建components和APIs时所犯的错误中总结的。我也努力的尝试的遵守我制定的规则，但是难免的在某些情况下我没有。

虽然不可能在每个场景or每个事件中应用到这些规则，但是如果尽可能的遵循这些规则，你将可能创造出一个设计良好的，灵活，可重用的components。让其他人一起享用的components。

你也许想要一个简单的提纲关于这些规则，下面的图片就是。我有全尺寸的图片版本托管在Flickr上。

如果你喜欢发布自己的components给别人去使用，就像我的MGTileMenu一样。那么也许你也想去读读我发的open source code（开源代码)，其中几个点也许会触及到。这篇文章也讨论了一些README文件，协议选择的相关事宜。