组件接口(API)设计指南[4]-通知(Notifications)

*返回文件夹阅读其它章节: http://blog.csdn.net/cuibo1123/article/details/39894477


通知(Notifications)

通知是托付协议的还有一半。我的立场是。假设你使用托付协议(你因该在全部适合的地方使用),就加入一个相同功能的通知。以使它提供完整的托付/通知方案。

在MGTileMenu中,你能够找到关于通知的接口文件:MGTileMenuController

规则23: 通知尾随托付方法

在托付方法(适当的。不是数据源方法)和通知之间存在着天生的对应关系。你能够在你代码的不论什么地方使用他们。而达到全然相同的目的。

假设你有一个关于事件发生的托付。你通常也应该提供一个相同目的的通知。做到即使把托付方法全部移除,使用者也依旧能够通过通知来实现对应功能。

托付方法的參数应该与通知的‘userInfo(通知附加值)’内容匹配。通知与您在托付中直接传递參数有一个明显的差别,它通常须要将信息装载到字典(NSDictionary)中。

托付方法:

- (void)tileMenuWillDisplay:(MGTileMenuController *)tileMenu;
- (void)tileMenuDidDisplay:(MGTileMenuController *)tileMenu;

对应的通知:

externNSString *MGTileMenuWillDisplayNotification;
externNSString *MGTileMenuDidDisplayNotification;

规则24: 不要吝啬‘userInfo(通知附加值)’

给通知对象所须要的足够信息。

请记住,通知接收器可能(差点儿总是会)不持有托付或数据源组件的引用。

问问自己什么是实用的,并提供对应信息。

最起码,你必须确保提供给对应托付方法的參数都包括在了userInfo的对象中。

托付方法:

- (void)tileMenu:(MGTileMenuController *)tileMenuwillSwitchToPage:(NSInteger)pageNumber;
- (void)tileMenu:(MGTileMenuController *)tileMenudidSwitchToPage:(NSInteger)pageNumber;

对应的通知:

// 通知userInfo包括一个键"MGPageNumber"
#defineMGPageNumberKey @"MGPageNumber"
externNSString *MGTileMenuWillSwitchToPageNotification;
externNSString *MGTileMenuDidSwitchToPageNotification;

规则25: 測试的地狱

最后,全部事情大家都已经知道了。

软件project专业化第101条:确保它确实能够工作。

是否使用正式的TDD(測试驱动开发)取决于你。但測试本身是不可能做到全面的。每个托付方法、每个通知、每个定制点所共同组成的千千万万种组合可能出现各种问题。

出现缺陷,首先应该找到并修复他们。假设你在赶时间,能够裁切功能。你一定会对无bug上线的问题感到苦恼。

阅读下一章节: http://blog.csdn.net/cuibo1123/article/details/39894477

-------------------------

英文原名《API Design》
       作者:Matt Gemmell
       原名链接:http://mattgemmell.com/api-design/

中文版由xoneday翻译
       欢迎訪问译者博客:http://blog.xoneday.com
       新浪微博:@xoneday某天

假设这片译文给您带来了帮助,希望您能通过下载我的APP来支持我:
豆瓣读书:https://itunes.apple.com/cn/app/id695492935
便签夹:https://itunes.apple.com/cn/app/id580552733

           

             便签夹                                        豆瓣读书


*转载声明:请勿删减作者/译者信息与支持部分的内容。如不接受此条款请勿转载。

时间: 2024-08-24 14:46:26

组件接口(API)设计指南[4]-通知(Notifications)的相关文章

组件接口(API)设计指南-目录

组件接口(API)设计指南-目录 组件接口(API)设计指南[1]-要考虑的问题 组件接口(API)设计指南[2]-类接口(class interface)  (排版中,待续) 组件接口(API)设计指南[3]-委托(delegate)和数据源协议(data-source protocols)  (排版中,待续) 组件接口(API)设计指南[4]-通知(Notifications)  (排版中,待续) 组件接口(API)设计指南[5]-最后的思考  (排版中,待续) 快速摘要: 译者注: 原文中

组件接口(API)设计指南-文件夹

组件接口(API)设计指南-文件夹 组件接口(API)设计指南[1]-要考虑的问题 组件接口(API)设计指南[2]-类接口(class interface) 组件接口(API)设计指南[3]-托付(delegate)和数据源协议(data-source protocols) 组件接口(API)设计指南[4]-通知(Notifications) 组件接口(API)设计指南[5]-最后的思考 高速摘要: 译者注: 原文中"delegate"译为中文"托付/代理",含义

组件接口(API)设计指南[1]-要考虑的问题

*返回目录阅读其他章节: http://blog.csdn.net/cuibo1123/article/details/39894477 在开发程序时,我会经常设计一些可重复使用的API,这些组件通常是针对IOS的(有时也会运行在MacOS上),并且大部分是关于GUI控件或某种视图的组件. 这些年来我已经设计了数十个API组件,这其中也包括一些Apple客户端程序,在这个过程中我学会了很多东西.我还会定期发布开源组件,用户的反馈对我也很有帮助.我整理出了一套设计API的准则与大家分享. 这是一个

组件接口(API)设计指南[3]-委托(delegate)和数据源协议(data-source protocols)

*返回目录阅读其他章节: http://blog.csdn.net/cuibo1123/article/details/39894477 委托(delegate)和数据源协议(data-source protocols) 委托协议是一个非常好的设计,它能让你用简单灵活的方式去实现MVC模式,并能增强松散耦合以及养成良好的API设计习惯. 这里是MGTileMenu的委托协议. 我们几乎可以在任何组件中利用经典的委托(delegate)和数据源协议(data-source protocols).如

组件接口(API)设计指南[5]-最后的思考

*阅读其它章节: http://blog.csdn.net/cuibo1123/article/details/39894477 最后的思考 我通过困难的学习以及多年的失误.写了这片篇关于创建组件和api规则的文章.我在试着练习我的写作能力,尽管不可避免地会出现非常多我没有提及的样例. 不是全部的规则都适用于全部情况,也没有一条规则在不论什么情况下适用.这里仅仅是尽可能多的给你一些灵感,使你为自己和他人设计更灵活.可重用的组件. 你可能须要一个全部规则的高速摘要,如图所看到的.我的flickr上

组件接口(API)设计指南[2]-类接口(class interface)

*返回文件夹阅读其它章节: http://blog.csdn.net/cuibo1123/article/details/39894477 类接口(class interface) 你能够參考MGTileMenu的接口文件. 我们之前谈论了一些接口的细节,这里,例举几个通用规则: 规则1:使用当前平台的描写叙述用语或构架 一个最常见的API错误设计是使用外来的规则,API属于一个特定的平台和相关开发人员生态系统. 你不能使用不论什么其它不同平台的描写叙述用语或构架,这会污染你当前的代码库,并破坏

来自HeroKu的HTTP API 设计指南(中文版)

原文转自:http://get.jobdeer.com/343.get 来自HeroKu的HTTP API 设计指南(中文版) 翻译 by @Easy 简介 本指南中文翻译者为 @Easy ,他是国内首家互联网人才拍卖网站 JobDeer.com 的创始人.转载请保留本信息. 本指南描述了一系列 HTTP+JSON API 的设计实践, 来自并展开于 Heroku Platform API 的工作.本指南指导着Heroku内部API的开发,我们希望也能对Heroku以外的API设计者有所帮助.

RESTful API 设计指南

RESTful API 设计指南 本人来源于:http://www.ruanyifeng.com/blog/2014/05/restful_api.html 作者: 阮一峰 日期: 2014年5月22日 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比

【转载】RESTful API 设计指南

作者: 阮一峰 日期: 2014年5月22日 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"API First"的设计思想.RESTful API是目前比较成熟的一套互联网应用程序的API设计理论.我以前写过一篇<理解RESTful架构>,探讨如何理解这个概念. 今天,我将介绍RESTful API