Atitit. Api 设计 原则 ---归一化

1.1. 叫做归一化1

1.2. 归一化的实例:一切对象都可以序列化/toString  通过接口实现1

1.3. 泛文件概念、2

1.4. 游戏行业的一切皆精灵2

1.1. 叫做归一化

接口继承实质上是要求“做出一个良好的抽象,这个抽象规定了一个兼容接口,使得外部调用者无需关心具体细节,可一视同仁的处理实现了特定接口的所有对象”——这在程序设计上,叫做归一化

归一化使得外部使用者可以不加区分的处理所有接口兼容的对象集合——就好象linux的泛文件概念一样,所有东西都可以当文件处理,不必关心它是内存、磁盘、网络还是屏幕(当然,如果你需要,当然也可以区分出“字符设备”和“块设备”,然后做出针对性的设计:细致到什么程度,视需求而定)。

1.2. 归一化的实例:一切对象都可以序列化/toString  通过接口实现

a、一切对象都可以序列化/toString
b、一切UI对象都是个window,都可以响应窗口事件。

——必须注意,是一切(符合xx条件的)对象皆可以做什么,而不是“一切皆对象”。后者毫无意义。

软件设计同样。比如说,消息循环在派发消息时,只需知道所有UI对象都是个window,都可以响应窗口消息就足够了;它没必要知道每个UI对象究竟是什么——该对象自己知道收到消息该怎么做。

合理划分功能层级、适时砍掉不必要的繁杂信息,一层层向上提供简洁却又完备的信息/接口,高层模块才不会被累死——KISS是最难也是最优的软件设计方法,没有之一。

总结:面向对象的好处实际就这么两点。
一是通过封装明确定义了何谓接口、何谓接口内部实现、何谓接口的外部调用者,使得大家各司其职,不得越界;
二是通过继承+多态这种内置机制,在语言的层面支持归一化的设计,并使得内行可以从代码本身看到这个设计——但,注意仅仅只是支持归一化的设计。不懂如何做出这种设计的外行仍然不可能从瞎胡闹的设计中得到任何好处。

显然,不用面向对象语言、不用class,一样可以做归一化的设计(如老掉牙的泛文件概念、游戏行业的一切皆精灵),一样可以封装(通过定义模块和接口),只是用面向对象语言可以直接用语言元素显式声明这些而已;
而用了面向对象语言,满篇都是class,并不等于就有了归一化的设计。甚至,因为被这些花哨的东西迷惑,反而更加不知道什么才是设计。

1.3. 泛文件概念、

1.4. 游戏行业的一切皆精灵

事实上,unix系统提出泛文件概念时,面向对象语言根本就不存在;游戏界的精灵这个基础抽象,最初是用C甚至汇编写的;……。

作者:: 绰号:老哇的爪子 ( 全名::Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 )

汉字名:艾提拉(艾龙),   EMAIL:[email protected]

转载请注明来源: http://www.cnblogs.com/attilax/

Atiend

时间: 2024-07-30 17:25:17

Atitit. Api 设计 原则 ---归一化的相关文章

atitit.api设计 方法 指南 手册 v2 q929.docx

atitit.api设计 方法 指南 手册 v2 q929.docx atitit.api设计原则与方法 1. 归一化(锤子钉子理论)1 1.1. 链式方法2 1.2. 规则5:建立返回值类型2 1.3. 参数接收 JSON 对象2 1.4. 参数默认值2 1.5. 命名参数 support by map2 1.6.  处理类型 类型自动转换4 1.7.  处理 undefined null  empty5 1.8. .使用结构化语法5 1.9. 设置和获取操作,可以合二为一:方法越多,文档可能

JavaScript API 设计原则

网+线下沙龙 | 移动APP模式创新:给你一个做APP的理由>> 好的 API 设计:在自描述的同时,达到抽象的目标. 设计良好的 API ,开发者可以快速上手,没必要经常抱着手册和文档,也没必要频繁光顾技术支持社区. 流畅的接口 方法链:流畅易读,更易理解 //常见的 API 调用方式:改变一些颜色,添加事件监听 var elem = document.getElementById("foobar"); elem.style.background = "red&

转载:阮一峰 Rest API设计原则

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

JavaScript 的 API 设计原则

前言 本篇博文来自一次公司内部的前端分享,从多个方面讨论了在设计接口时的原则,总共包含了七个大块.系卤煮自己总结的一些经验教训.同时也参考了一些文章,地址会在后面贴出来.很难做到详尽充实,如果有好的建议或者不对的地方,还望不吝赐教斧正. 一.接口的流畅性 好的接口是流畅易懂的,他主要体现如下几个方面: 1.简单 操作某个元素的css属性,下面是原生的方法: document.querySelectorAll('#id').style.color = 'red'; 封装之后 function a(

JavaScript的api设计原则

一.接口的流畅性 好的接口是流畅易懂的,他主要体现如下几个方面: 1.简单 操作某个元素的css属性,下面是原生的方法: document.querySelector('#id').style.color = 'red'; 封装之后 function a(selector, color) {  document.querySelector(selector).style.color = color } a('#a', 'red'); 从几十个字母长长的一行到简简单单的一个函数调用,体现了api简

深入浅析JavaScript的API设计原则(转载)

一.接口的流畅性 好的接口是流畅易懂的,他主要体现如下几个方面: 1.简单 操作某个元素的css属性,下面是原生的方法: ? 1 document.querySelectorAll('#id').style.color = 'red'; 封装之后 ? 1 2 3 4 function a(selector, color) { document.querySelectorAll(selector)[].style.color = color } a('#a', 'red'); 从几十个字母长长的一

RESTful API设计原则与规范

一.背景与基础概念 2 二.RESTful API应遵循的原则 3 1.协议(Protocol) 3 2.域名(ROOT URL) 3 3.版本(Versioning) 3 4.路径(Endpoints) 3 5.HTTP动词(HTTP Verbs) 4 6.过滤信息(Filtering) 5 7.状态码(Status Codes) 5 8.错误处理(Error handling) 6 9.返回结果(Response) 6 10.使用HATEOAS的Hypermedia API 6 11.认证(

出色的 JavaScript API 设计秘诀

设计是一个很普遍的概念,一般是可以理解为为即将做的某件事先形成一个计划或框架. (牛津英语词典)中,设计是一种将艺术,体系,硬件或者更多的东西编织到一块的主线.软件设计,特别是作为软件设计的次类的API设计,也是一样的.但是API设计常常很少关注软件发展,因为为其他程序员写代码的重要性要次于应用UI设计和最终用户体验. 但是API设计,作为我们自己写的库中提供的公共接口,能够向调用我们代码的开发者表现出我们库的一些特点和功能,所以API设计和UI设计一样重要.事实上,两者都是为应用可以提供更好的

app后端api设计【转】

博客:https://blog.csdn.net/newjueqi/article/details/44037011 app和后端的交互,一般都是通过后端提供的api实现.api的设计,估计很多刚进入app后端的小伙伴会一无头绪,不知道怎么入门.下面根据自己3年的app后端经验,总结出下几个api设计原则,给小伙伴参考. 1. 什么是api? 这个问题在以前发表的文章"7.app和app后端的通讯"中其实已经回答了,这里再重复一次. 相信大家都用过银行的柜员机(ATM)的查询余额,转帐