首页 > 代码库 > 组件接口(API)设计指南[1]-要考虑的问题

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

*返回目录阅读其他章节: http://blog.csdn.net/cuibo1123/article/details/39894477


    在开发程序时,我会经常设计一些可重复使用的API,这些组件通常是针对IOS的(有时也会运行在MacOS上),并且大部分是关于GUI控件或某种视图的组件。

    这些年来我已经设计了数十个API组件,这其中也包括一些Apple客户端程序,在这个过程中我学会了很多东西。我还会定期发布开源组件,用户的反馈对我也很有帮助。我整理出了一套设计API的准则与大家分享。

    这是一个重要的话题,无论你是一个开源贡献者,还是在一个团队中为一个大程序写模块,或者只是写你自己的软件。就像一个应用程序第一次启动带给用户的体验一样,你的API将是你代码质量的第一印象,这会对别人是否使用它(或者丢弃它)产生巨大的影响。

    API就像是开发人员的用户体验(UX)。我很惊讶,在这方面并没有很多资料可以参考,也没有一个专门讨论此话题的受欢迎的平台。

    我将用我最近发布的开源GUI组件MGTileMenu作为一个例子,来介绍一些准则。你可以阅读有关MGTileMenu的内容,如果你喜欢。


理想的品质

    API的设计非常类似与用户界面和用户体验设计。你的目标受众有不同的需要和特点,但他们的目标都是完成一项工作。作为一个友好的,可用的用户界面(UI),你必须试图让你的API:

1:直观(Intuitive)

2:宽容(Forgiving)

3:一致(Frictionless)

正如一款设计给人们使用的软件,我们必须考虑使用案例,我们必须保证用户很容易做出最常用、最需要的东西,并且不需要不必要的配置。默认的行为应该是有用的,并且因该是一种合理的选择。其次,该软件(或API)的功能应该是可被发现的,既允许用户从已知的范例推导其他使用方法,正如设计用户界面时要求操作方式符合一致的用户习惯一样。


接口

    开发人员与组件的显式交互主要有四种:

        1. 类接口(classinterface),类公开的属性和方法。

        2.委托协议(delegateprotocol),在相关的地方。

        3.数据源协议(data-sourceprotocol),酌情。

        4.规定的通知(notifications)。

    我们设计的每一种交互,都应该需要用户刻意的去使用,不要做隐式的交互调用。另外,你应当思考两个关键问题:

○ 什么是控制?

    控制会影响界面和类方法。它影响的界面是显而易见的,比如一个按钮,或者一个滑块。而它影响的方法则由代码决定。

○ 是什么样的控制?

    它需要哪些委托和/或数据源、通知。如果它是一个新类型的控制,那么它本质上是否和已有的控制方式非常相似?比如大纲视图是一个线性表。日历控件是一个日期选择器。命令的集合会呈现一个菜单等等。

    我们的核心目标是让它与现有的组件或模型相一致,这样使用者就可以很快的弄明白一个陌生控件。在可能的情况下(这几乎总是可能的),尽量使用(或模仿)标准的API。对于一些在代码级使用这些模块的用户,熟悉程度和直观性同样重要。


    下面,让我们来看看之前提到的四种显式交互方式在API中的应用。


阅读下一章节: 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

           

             便签夹                                        豆瓣读书


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






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