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

*阅读其它章节: http://blog.csdn.net/cuibo1123/article/details/39894477


最后的思考

我通过困难的学习以及多年的失误。写了这片篇关于创建组件和api规则的文章。我在试着练习我的写作能力,尽管不可避免地会出现非常多我没有提及的样例。

不是全部的规则都适用于全部情况,也没有一条规则在不论什么情况下适用。这里仅仅是尽可能多的给你一些灵感,使你为自己和他人设计更灵活。可重用的组件。

你可能须要一个全部规则的高速摘要,如图所看到的。我的flickr上有全尺寸版

假设你有兴趣开放你的组件供他人使用。你可能须要阅读我的关于公布开源码的观点,那里也谈到了怎么编写README文件,许可证选择等相关事宜。

我希望你喜欢这篇文章。假设你喜欢,或许你会考虑购我的非开源组件,或通过捐赠支持这个博客以后的文章。

我真的非常感激。

欲了解很多其它源于软件和用户体验的设计,以及其它话题,你能够在twitter上关注我(@mattgemmell)。也能够聘请我一同工作。

如今,你能够去制作伟大的软件了。

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

英文原名《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-10-24 23:54:33

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

组件接口(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)设计指南[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)设计指南[2]-类接口(class interface)

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

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

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

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

*返回文件夹阅读其它章节: http://blog.csdn.net/cuibo1123/article/details/39894477 通知(Notifications) 通知是托付协议的还有一半.我的立场是.假设你使用托付协议(你因该在全部适合的地方使用),就加入一个相同功能的通知.以使它提供完整的托付/通知方案. 在MGTileMenu中,你能够找到关于通知的接口文件:MGTileMenuController 规则23: 通知尾随托付方法 在托付方法(适当的.不是数据源方法)和通知之间存

来自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