USB 接口器件ISP1581 的接口应用设计概要
USB接口器件ISP1581的接口应用设计
■解放军信息工程大学王晖
摘要关键词简单介绍USB接口的特点和Philips公司的USB接口芯片ISP1581;详细介绍USB接口的硬件原理设计、固件开发流程及USB设备的调试。
USB ISP1581固件枚举微控制器接口DMA
引言
通用串行总线USB(Universal Serial Bu s是近年来应用在PC领域的新型接口技术;是一些大PC厂商,如Microsoft、Int el等,为了解决日益增加的PC外设与有限的主板插槽和端口之间的矛盾,而制定的一种串行通信的标准。USB以其高速、易于安装配置、使用灵活和可靠性高而日益受到人们的欢迎。现在已广泛使用于计算机和周边设备的连接,如键盘、鼠标、打印机、存储设备等。
USB控制器一般有两种类型:一种是MCU集成在芯片里面;另一种是纯粹的USB接口芯片,仅处理 USB 通信。前者由于开发时需要单独的开发系统,因此开发成本较高;后者只是一个芯片与MCU接口,实现USB 通信功能,因此成本较低、可靠性较高。本文主要介绍Philips公司的ISP1581器件的使用方法,它属于后者。1硬件设计
1.1I S P1581芯片特点
ISP1581 是一个高速USB 器件控制器。它实现了USB 2.0/1.1 物理层和数据协议
层的任务,并且实现了
连同端点EP0 (设置用于
访问设置缓冲器在内的
16 个USB 端点的共同协
作;用于基于微控制器
的系统,与微控制器/微
处理器的通信是通过一
个高速的通用并行接口
实现的,接口速度可达
12.5M字节/s或12.5
M字/s;支持DMA传输,
可很好地实现与大容量
存储设备的接口;通过ATA/A TAPI接口,可以直接与ATA/A TAPI设备相连。ISP1581能适应大多数设备类规范的设计,非常适合做很多外围设备,如打印机、扫描仪、外部大容量存储器和数码相机等的外部接口。(注: ATA/A TAPI,Advanced Technology Attachmen t/Advanced Technology Attachment Peripheral Int erface。中文名称为高级技术附加装置/高级技术附加装置外围接口。ATA是一种硬盘接口标准,ATA标准的接口类型其实就是IDE 接口类型。
1.2I S P1581内部模块功能描述
ISP1581内集成了多个模块,各自完成不同功能,如图1所示。
① USB2.0收发器。模拟收发器通过集成的终端电阻直接与USB电缆相连。
② Philips串行接口引擎(SIE,Serial Interface Engine。完成所有USB协议层的功能,主要完成以下的功能:同步方式的识别、并行/串行的转换,位填充/解除填充、CRC校验/产生、包标识(PID校验/产生、地址识别和握手评估/产生。考虑到速度,它是全硬件的,不需要
DREQ,DACK
CS0,CS1,
[16:0]
DS/WR
图1ISP1581内部结构方框图
固件介入。
③存储器管理单元(M M U和集成RA M 。MMU 和集成RAM 实现了USB 总线和微控制器管理器或DMA 管理器之间的速度转换。
④微控制器/处理器接口和微控制器/处理器的管理器。可以直接与大部分微控制器相连。
⑤ DMA 接口和DMA 管理器。DM A 管理器接收到DMA 命令后,可直接把数据从内部RAM 传送到外部DM A 设备或从外部DM A 设备传送给内部RAM 。
2硬件连接
ISP1581 有一个快速通用接口,利用它可以实现与大
部分类型的微控制器/处理器的通信。上电时,由引脚BUS_CONF 、MODE1 和MODE0 共同设置。由于MMC2107的外部地址、数据总线是分开的,因此在本开发平台上ISP1581只能工作在通用处理器工作模式下,设置方式如表1所列。
ISP1581提供微控制器接口与微控制器进行数据传输,也支持DMA 传输。在微控制器速度较高时,两者的读写访问速度均可达12.5M b/s ,采用DMA 方式会增加电路设计的复杂度。经过综合比较,采取微控制器接口方式。USB 模块硬件连接原理如图2所示。
注:①ISP1581提供两种复位方式:a. ISP1581集成有上电复位电路(POR, RESET 引脚接电源,实现上电复位功能。b. RESET 引脚接MMC2107的一个数字I/O 引脚,
将该引脚置低800μs 后置高,实现复位。②ISP1581 的供电电压为3.3V 或5.0V ,I/O 引脚最大能承受5.0V 的电压。根据I/O 口的电压,从3.3V 和5.0V 中选择一个作为供电电压。
3I S P 1581固件(F I R E W A R E 程序设计
由于所有的通信都是由主机发起,设备只能响应来
自主机的命令。在这种结构下,ISP1581的固件采取中断驱动。这样一方面保证了快速的数据传输和较好的软
件结构,另一方面简化了编程和测试。
固件程序由5部分组成,如图3所示。(1主循环流程
上电后,初始化MMC2107和ISP1581。然后,主循环程序轮询检查事件标志,进入相应的子程序进行进一步的处理。图4是主循环的流程。
表1设置工作方式
注:这里使用16位总线,AD[0]必须与ISP1581的地端相连。
图3固件结构和数据流向
图4USB主循环程序
图2MMC2107与ISP1581硬件连接原理
(2中断服务程序(ISR流程
图5所示的中断服务流程,用来处理由ISP1581产生的中断。通过访问ISP1581的中断寄存器,建立正确的事件标志,以通知主循环程序进行处理。(3USB 标准请求处理
进行应用通信以前,主机必须枚举设备。该过程是通过给端点0发送包含标准设备请求(CHA P_9的控制传
输实现的。USB 标准请求流程(见图6译码设备请求类型,转到相应的处理子流程。枚举过程如下:
①主机使用默认地址(地址0读取设备描述符G etDeviceDescriptor ;
② SetAddress ;
③连续3次G etDev iceDescriptor ,读取全部设备描述符;
④ G etConfigDescriptor ;
⑤ G etStringDescriptor(可能没有;
⑥读取全部ConfigDescriptor 后,主机将找到新设备,提示安装驱动程序。
⑦在设备能通信前,主机给出SetConfiguration 请求,设备收到后调整有关信息,使设备能被客户软件利用。(4厂商请求处理(VENDOR
厂商请求和USB 标准请求一样,都根据控制传输的内容进行相应处理。本开发平台的固件程序中定义了两个厂商请求,分别为取得固件版本和将批量数据写入设备或从设备中读出数据。
取得固件版本流程如图7所示。主机发送批量数据读写请求时,在控制传输的数据阶段,主机给出需要传输的数据字节数、数据传输方向、页索引和数据定位。控制传输结束后,主机和设备就可以根据双
方约定,启动批量传输。批量传输流程如图8所示。
4
调试
4.1
调试步骤
USB 的调试可分为以下几个步骤:
①若USB 芯片正常工作,可实现软连接,将设备插
入主机后,主机上出现“未知设备类型”的USB 设备;
②提供描述符,提供正确的VID 和PID 后,主机能够识别设备,但要求提供设备的驱动程序;
③安装驱动程序后,调试各端点,使其均可传输数据,用主机端的测试程序对其进行测试,验证硬件及固件的正确性。
中断服务程序
图5中断服务程序流程
图6USB标准设备请求流程
取得固件版本
图7取得固件版本流程
图8批量传送流程
4.2调试工具
因为每一次USB的传输过程,都有时效要求,等待时间过长,通信过程也就中止了,因此不适合用硬件仿真器来设断点调试。可采用串口辅助调试过程,即在固件代码中加入类似于Printf的语句,向串口输出一些信息。借此,可以知道程序是否运行到此处,以及运行到此处时相应的变量或寄存器值。
设备完成配置后,在Bus Hou nd中可看到该设备(bus Hound是一种应用软件。选择该设备,就可以对主机与此设备间的通信数据进行分析和监视。Bus Hound 工作在主机端,串口工作在微控制器端。将串口调试和Bus Hound两种手段配合使用,可以使USB通讯过程的调试更加容易。
在调试USB设备时,还可使用UsbView程序。在该程序中可以查看设备描述符、配置描述符和端点描述符是否正确。
(收稿日期:2004-02-24
接口设计规范
目录 1接口类型 (2) 1.1人机接口 (2) 1.2软件-硬件接口 (2) 1.3软件接口 (2) 1.4通信接口 (2) 2接口设计规范 (2) 2.1基本内容 (2) 2.2规格说明 (3) 2.2.1人机接口 (3) 2.2.2软件-硬件接口 (3) 2.2.3软件接口 (3) 2.2.4通信接口 (3) 3接口设计文档提纲 (3)
1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。 2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系 4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求
9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。 2.2.4通信接口 逐个描述各个通信接口的设计特性。包括硬件描述、接口功能说明、通信协议、报文处理、存储资源分配、程序接口设计和程序编制要求等。 3接口设计文档提纲 1概述........................................................................................................................................................... 错误！未定义书签。 1.1编写目的......................................................................................................................................... 错误！未定义书签。 1.2参考资料......................................................................................................................................... 错误！未定义书签。 1.3术语和缩写词................................................................................................................................ 错误！未定义书签。2软件系统综述......................................................................................................................................... 错误！未定义书签。3接口设计.................................................................................................................................................. 错误！未定义书签。 3.1接口框图......................................................................................................................................... 错误！未定义书签。 3.2接口一览表.................................................................................................................................... 错误！未定义书签。 3.3人机接口......................................................................................................................................... 错误！未定义书签。 3.4软件-硬件接口 .............................................................................................................................. 错误！未定义书签。
接口设计规范V1.0 - 参考
服务端与手机平台 接口协议 BespRout 2014年11月
文档修改/审批记录
目录 1.概述 (4) 2.涉及接口 (4) 3.接口总体要求 (4) 3.1.系统间接口的原则 (4) 3.2.处理流程 (4) 3.3.接口实现方式 (5) 4.XXX服务端接口 (5) 4.1.XX模块-根据XX下载相关的配置文件 (5) 4.2.XX模块-生成指定XX的文件配置 (6) 4.3.APP启动-初使化参数 (7) 5.附件 (8) 5.1.备注说明 (8)
1. 概述 本文档提供接口给手机端使用，为手机端提供业务平台数据 2. 涉及接口 本文档涉及的外围系统接口包括：无 3. 接口总体要求 3.1.系统间接口的原则 接口设计遵循如下原则： ?安全可靠性原则：系统应提供良好的安全性和可靠性策略，支持多种安全而 可靠的技术手段，制定严格的安全可靠的管理措施； ?开放性原则：提供开放式标准接口，提供与其它系统的互联互通； ?灵活性原则：提供灵活的接口设计，便于接口的变动。 ?可扩展性原则：支持新业务的扩展以及接口容量与接口性能的提高； ?可管理性原则：提供良好的管理机制，保证在运行过程中提供给管理员方便 的管理方式以处理各种情况； ?统一性原则：应当保证系统的接口方式、接口形式、使用的协议等标准、统 一。 3.2.处理流程 接口处理流程
3.3. 接口实现方式 手机APP 应用 与服务端采用基于HTTP 的REST 协议完成，数据传输默认为JSON 4. XXX 服务端接口 测试地址前缀: http://192.168.3.208:8088/xxx/xxx 4.1. XX 模块-根据XX 下载相关的配置文件
六大设计原则
设计模式六大设计原则 单一职责原则(Single Responsibility Principle-SRP) 理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。 应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！开放封闭原则(open closed principle-OCP) 理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。 里氏替换原则(liskov substitution principle -LSP) 理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。 应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的public 方法供外界调用。 最少知识原则(last knowledge principle-LKP) 理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。 应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。 接口隔离原则(Interface Segregation Principle - ISP) 理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。 应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。 依赖倒置原则(Dependence Inversion Principle – DIP) 理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。 应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
关于APP接口设计
最近一段时间一直在做APP接口，总结一下APP接口开发过程中的注意事项： 1、效率：接口访问速度 APP有别于WEB服务，对服务器端要求是比较严格的，在移动端有限的带宽条件下，要求接 口响应速度要快，所有在开发过程中尽量选择效率高的框架，PHP建议使用YAF框架。 2、数据格式 最好使用JSON格式数据，因为JSON有较好的跨平台性。对于 3、数据量 按需分配，APP客户端需要什么数据就返回什么数据，过多的数据量影响处理速度，最重要的 是影响传输效率。 4、接口、参数命名准确 无论是接口还是参数，命名都应该有意义，让人一目了然。 5、一个页面尽可能就用一个接口 现在很多的APP页面都有广告、焦点图、文章列表等，对于这些不同格式的数据，不可能都分 配一个接口，这样加大了APP请求接口数，影响响应速度。建议服务器端尽可能处理好数据后 通过一个接口返回给APP客户端。 6、缓存 这点比较重要，不管是文件缓存还是memcache缓存。 7、接口要有可扩展性 8、接口安全 目前一般都是在APP客户端和服务器通过约定的算法，对传递的参数值进行验证匹配。但是如 果APP程序被反编译，这些约定的算法就会暴露，特别是在安卓APP中，有了算法，完全就 可以通过验证模拟接口请求。 9、接口版本控制 对于接口版本控制，自己目前也没有找到一个好的方法，怎么去应对不断的APP版本升级，新、旧接口的处理。 10、接口数据、状态 接口必须提供明确的数据状态信息，不管是成功的，还是失败的，都必须返回给APP客户端。 以上10点就是自己在这端时间做APP接口过程中注意的事项，写的有点乱，想到什么就写什么。
接口与接口设计原则
接口与接口设计原则 一．11种设计原则 1.单一职责原则 - Single Responsibility Principle(SRP) 就一个类而言，应该仅有一个引起它变化的原因。职责即为“变化的原因”。 2.开放-封闭原则 - Open Close Principle(OCP) 软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 ) 3.里氏替换原则 - Liskov Substitution Principle(LSP) 子类型(subclass)必须能够替换掉它们的基类型(superclass)。 4.依赖倒置原则(IoCP) 或依赖注入原则 - Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原则: "Don't call us, we'll call you". 程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。任何方法都不应该覆写他的任何基类中的已经实现了的方法。 5.接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。 6.重用发布等价原则(REP) 重用的粒度就是发布的粒度。 7.共同封闭原则(CCP) 包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。 8.共同重用原则(CRP) 一个包(类库、DLL)中的所有类应该是共同重用的。 如果重用了包(类库、DLL)中的一个类，
程序设计七大原则
软件设计的七大原则 设计模式遵循的一般原则： 1.开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。 2.里氏代换原则(Liskov Substitution Principle,常缩写为.LSP) (1).由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。 (2).严格表达:如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型. 换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
(3).反过来的代换不成立 (4).<墨子.小取>中说:"白马,马也; 乘白马,乘马也.骊马(黑马),马也;乘骊马,乘马也." (5).该类西方著名的例程为:正方形是否是长方形的子类(答案是"否")。类似的还有椭圆和圆的关系。(6).应当尽量从抽象类继承,而不从具体类继承,一般而言,如果有两个具体类A,B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B 成为抽象类C的子类.即如果有一个由继承关系形成的登记结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类;而所有的树枝节点都应当是抽象类或者接口. (7)."基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍: 使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的
RESTful API设计原则与规范
RESTful API设计原则与规范 一、背景与基础概念 2 二、RESTful API应遵循的原则 3 1、协议(Protocol) 3 2、域名(ROOT URL) 3 3、版本(Versioning) 3 4、路径(Endpoints) 4 5、HTTP动词(HTTP Verbs) 5 6、过滤信息（Filtering） 6 7、状态码（Status Codes）7 8、错误处理（Error handling）8 9、返回结果（Response）8 10、使用HATEOAS的Hypermedia API 8 11、认证（Authentication）9 三、Swagger API标准9
REST，即Representational State Transfer的缩写。RESTful架构，是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制，所以正得到越来越多网站的采用。如果一个架构符合REST原则，就称它为RESTful架构。 本文即将描述的，即是创建RESTful架构的API所要遵循的原则与规范。 一、背景与基础概念 Web 应用程序最重要的REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。 ?资源（resource）：网络上的一个实体或者说是一个具体信息，可以是一段文本、一张图片、一首歌曲、一种服务。 ?统一资源定位符（URI，Universal Resource Identifier）：一个资源的识别符或者说是一个地址，通过URI你可以定位到特定的资源。要获取这个资源，需要访问它的URI，因此，URI就成了每一个资源的地址或独一无二的识别符。 ?状态转换（State Transfer）: 所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。客户端与服务器互动的过程，通常涉及到服务器端数据和状态的变化过程，比如文件被修改，访问数量增加等。
软件接口设计指南
软件接口设计指南 拟制人日期 审核人日期 批准人日期
目录 1目的 (1) 2适用范围 (1) 3参考文件 (1) 4定义和缩写 (1) 5规定 (1) 5.1JAVA接口设计方法 (1) 5.2C++接口设计方法 (5) 5.3接口设计对软件性能的影响 (7) 5.4面向对象设计中，接口设计的一般原则 (10) 6附件 ............................................................................................................................... 错误！未定义书签。
1目的 为大家在进行软件接口设计时提供一些指导，以帮助大家更好的理解软件接口设计的方法和原则。 2适用范围 适用于公司软件开发的接口设计过程。 3参考文件 本过程文件中的过程裁剪应依据《组织标准过程裁剪指南》的规定。 4定义和缩写 本过程文件的编写依据是美国软件工程研究院（SEI）的集成成熟度模型软件分支1.2版本（CMMI-DEV V1.2）。 5规定 5.1JAVA接口设计方法 我们在设计系统接口时，经常会遇到这样的问题： 我们的接口应该提供多少方法才合适？ 我们的接口应该提供"原子方法"还是"复合方法"？ 我们的接口是否应该封装（或者，能否封装）所有的细节？ 接口的设计需要考虑用户的使用习惯、使用的方便程度、使用的安全程度，根据我的编程经验，下面会详细讨论接口设计的2个需要权衡的方面：接口的单一化 & 复合化。 接口 接口提供了不同系统之间或者系统不同组件之间的界定。在软件中，接口提供了一个屏障，从而从实现中分离目标，从具体中分离抽象，从作者中分离用户。 站在用户的角度看，一个接口建立并命名了一个目标对象的使用方法。一些约束（例如：编译时的类型系统、运行时的异常机制及返回值）使得类作者的目的得以体现和加强。供给（affordances）指事物的被感知的真实的属性，这些属性可以决定事物使用的可能方法，供给提供了对事物操作的线索。 类设计者的一个职责便是在接口中减小约束与供给之间的隔阂、匹配目标以及一定程度上的自由度，尽可能减小错误使用目标对象的可能。 封装 对于封装来说，远不止数据私有那么简单。在设计中，封装往往会涉及到自我包含（self-containment）。如果一个类需要你知道如何调用它方法（e.g. 在一个线程的环境中，在一个方法调用后调用另一个方法，你必须明确地同步对象），那么它的封装性就不如将所有这些全部包含并隐藏的类（e.g. 这个类是thread-safe的）好。前一个设计存在着设计的漏洞，它的许多限定条件是模糊的，而且把部分责任推给了用户，而不是让类提供者做这些工作来完成类的设计。 在空间或者时间上分离方法的执行（例如，线程，远程方法调用，消息队列），能够对设计的正确性和效率产生意义深远的影响。这种分离带来的结果是不可忽视的：并发引入了不确定性和环境（context）选择的开销；
面向对象类的设计原则
类的设计原则 2009-12-23 来源：https://www.wendangku.net/doc/b02865164.html, 闭原则 oftware entities (classes, modules, function, etc.) should be open for extension, but closed for modification. 软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。 开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其他程序单位时，应该遵循： 扩展开放（open） 修改关闭（closed） 计原则。 开闭原则是判断面向对象设计是否正确的最基本的原理之一。 根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。 扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。 这也是系统设计需要遵循开闭原则的原因： ）稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。 ）扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。 遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。 开闭原则的实现方法 为了满足开闭原则的对修改关闭（closed for modification）原则以及扩展开放（open for extension）原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中， 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展； 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现； 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。 接口可以被复用，但接口的实现却不一定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能件系统的柔软扩展。
类的设计原则
开闭原则 Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification. 软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。 开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其他程序单位时，应该遵循： - 对扩展开放（open） - 对修改关闭（closed） 的设计原则。 开闭原则是判断面向对象设计是否正确的最基本的原理之一。 根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。 - 扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。 - 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。 这也是系统设计需要遵循开闭原则的原因。 1）稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。 2）扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。 遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。 开闭原则的实现方法 为了满足开闭原则的对修改关闭（closed for modification）原则以及扩展开放（open for extension）原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中， - 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展； - 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现； - 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。
六大设计原则超详细介绍
六大设计原则超详细介绍 软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的，我们要为不可预料的变化做好准备，这本身是一件非常痛苦的事情，但好在有大师们已经给我们提出了非常好的六大设计原则和23种设计模式来“封装”未来的变化。本文只针对六大设计原则进行介绍，设计模式放在后面的文章进行详解。 六大设计原则 六大设计原则主要是指： 单一职责原则（Single Responsibility Principle）；开闭原则（Open Closed Principle）；里氏替换原则（Liskov Substitution Principle）；迪米特法则（Law of Demeter），又叫“最少知道法则”；接口隔离原则（Interface Segregation Principle）；依赖倒置原则（Dependence Inversion Principle）。把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是：SOLID（稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计。 单一职责原则 单一职责原则的定义是：应该有且仅有一个原因引起类的变更。 没错，单一职责原则就这一句话，不懂没关系，我们举个例子。 我们以打电话为例，电话通话的时候有4个过程发生：拨号、通话、回应、挂机。那我们写一个接口，类图如下：
代码为： 我们看这个接口有没有问题？相信大部分同学会觉得没问题，因为平常我们就是这么写的。没错，这个接口接近于完美，注意，是“接近”。单一职责原则要求一个接口或一个类只能有一个原因引起变化，也就是一个接口或者类只能有一个职责，它就负责一件事情，看看上面的接口只负责一件事情吗？明显不是。 IPhone这个接口包含了两个职责：协议管理和数据传送。dial和hangup这两个方法实现的是协议管理，分别负责拨号接通和挂机，chat方法实现的是数据传送。不管是协议接通的变化还是输出传送的变化，都会引起这个接口的变化。所以，IPhone这个接口并不符合单一职责原则。若要让IPhone满足单一职责原则，我们就要对其进行拆分，拆分后的类图如下： 这样设计就完美了，一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化了啊，是的，但是别忘了我们是面向接口编程，我们对外公布的是接口而不是实现类。
接口设计的十一种原则
接口设计的 11 种原则收藏 7种设计坏味道 1.僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。 2.脆弱性：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。 3.牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。 4.粘滞性：做正确的事情比做错误的事情要困难。 5.复杂性(不必要的)：设计中包含有不具任何直接好处的基础结构。 6.重复性(不必要的)：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。 7.晦涩性：很难阅读、理解。没有很好地表现出意图。 11种原则- Principle ----类原则 1.单一职责原则- Single Responsibility Principle(SRP) 就一个类而言，应该仅有一个引起它变化的原因。 (职责即为“变化的原因”。) 2.开放-封闭原则 - Open Close Principle(OCP) 软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。 (对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来. 开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要. ) 3.里氏替换原则- Liskov Substitution Principle(LSP) 子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或依赖注入原则- Dependenc e Inversion Principle(DIP) 抽象不应该依赖于细节。细节应该依赖于抽象。 (Hollywood原则: "Don't c all us, we'll call you". 程序中所有的依赖关系都应该终止于抽象类和接口。 针对接口而非实现编程。 任何变量都不应该持有一个指向具体类的指针或引用。 任何类都不应该从具体类派生。 任何方法都不应该覆写他的任何基类中的已经实现了的方法。) 5.接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法。 接口属于客户，不属于它所在的类层次结构。 (多个面向特定用户的接口胜于一个通用接口。) ----包内聚原则 6.重用发布等价原则(RE P) 重用的粒度就是发布的粒度。 7.共同封闭原则(CCP) 包中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包产生影响， 则将对该包中的所有类产生影响， 而对于其他的包不造成任何影响。 8.共同重用原则(CRP) 一个包中的所有类应该是共同重用的。
接口设计原则
一、接口的设计依据： 接口要符合rest、命名要规范优雅、单一性、扩展性 1.1 接口要符合rest REST的要求: 客户端和服务器结构（通信只能由客户端单方面发起，表现为请求-响应的形式。） 连接协议具有无状态性（通信的会话状态（Session State）应该全部由客户端负责维护。）能够利用Cache机制增进性能（响应内容可以在通信链的某处被缓存，以改善网络效率。）一致性的操作界面（通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。）层次化的系统（通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。） 1.2 接口命名一定要规范 ①命名以英文或者英文缩写并以驼峰命名法命名 ②返回字段中表示同一个含义的字段在不同接口中命名尽量一致 1.3单一性、粒度合适 单一性是指接口要做的事情应该是一个比较单一的事情，比如登陆接口，登陆完成应该只是返回登陆成功以后一些用户信息即可，但很多人为了减少接口交互，返回一大堆额外的数据。比如有人设计一个用户列表接口，接口他返回每一条数据都是包含用户了一大堆跟另外无关的数据，结果一问，原来其他无关的数据是他下一步想要获取的，他想要懒加载，但这是一个工作多年的人设计的吗？(如此次有为患者端接口此类问题明显医护端首页待接订单中 请求接口将两种类型订单和在一块导致无法分页请求问题) 1.4 扩展性 这边的扩展性是指我们的接口充分考虑客户端，想想他们是如何调用的，他要怎样使用我的代码，他会如何扩展我的代码，不要把过多的工作写在你的接口里面，而应该把更多的主动权交给客户程序员。如获取不同的列表数据接口，我们不可能将每个列表都写成一个接口。还有一点，我这里特别想指出来的是很多开发人员为了省事（姑且只能这么理解），将接口设计当成只是app页面展示，这些人将一个页面展示就用一个接口实现，而不考虑这些数据 是不是属于不同的模块、是不是属于不同的展示范畴、结果下次视觉一改，整个接口又得重写，不能复用。 1.5 文档表述要清晰 良好的接口设计，离不开清晰的接口文档表述。文档表述一定要足够详细。 二、接口入参、返回数据包具体原则 2.1 入参 根据接口是否是涉及业务流程来判断是否添加相关校验参数（如目前的五个基本参数：在版本更新时不要基本参数传入；用户接单需要传入基本参数）。
接口设计六大原则
接口设计六大原则 一.单一职责原则 Single Responsibility Principle, 简称SRP。 定义：There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更。 职责的划分？单一的定义和级别？ 应该根据实际业务情况而定。关注变化点。 实际使用时，类很难做到职责单一，但是接口的职责应该尽量单一。 二.里氏替换原则 Liskov Substitution Principle, 简称LSP。 定义：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. (所有引用基类的地方必须能透明地使用其子类的对象) 里氏替换原则为良好的继承定义了一个规范： 1.子类必须完全实现父类的方法 2.子类可以有自己的个性（属性和方法）。 3.覆盖或实现父类的方法时输入参数可以被放大。
4.覆写或实现父类的方法时输出结果可以被缩小。 注：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了ＬＳＰ原则。 三.依赖倒置原则 Dependence Inversion Principle, 简称DIP 定义：High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions. 翻译过来，包含三层含义： 1.高层模块不应该依赖低层模块，两者都应该依赖其抽象。 2.抽象不应该依赖细节。 3.细节应该依赖抽象。 精简的定义：面向接口编程。 Test-Driven Development 测试驱动开发是依赖倒置原则的最好体现。 测试驱动开发要求先写测试类，测试通过才写实现类，这就要求你要先想接口定义。 依赖的三种写法： 1.构造函数传递依赖对象。 2.Setter方法传递依赖对象。
API接口设计原则
API接口设计原则 一、针对接口编程，而不是针对实现编程 –客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。 小注： 接口是定义行为，只是定义我们要做什么事情，至于如何做这些事情是由接口的实现来做的，当我们定义接口的时候无需关心这个行为如何实现，只要知道有这个接口就可以。 别人在调用你的代码的时候，都是调用你的接口对象，至于如何实现，对别人是透明的。 二、优先使用对象组合，而不是类继承 –类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封 装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。 小注： 因为继承在编译时刻就定义了，所以无法在运行时刻改变从父类继承的实现。更糟的 是，父类通常至少定义了部分子类的具体表示。因为继承对子类揭示了其父类的实现细节，所以继承常被认为“破坏了封装性”。子类中的实现与它的父类有如此紧密的依赖关系，以 至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，实现上的依赖性就会产生一些问题。如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。一个可用的解决方法就是只继承抽象类，因为抽象类通常提供较少的实现。 对象组合是通过获得对其他对象的引用而在运行时刻动态定义的。组合要求对象遵守 彼此的接口约定，进而要求更仔细地定义接口，而这些接口并不妨碍你将一个对象和其他对象一起使用。这还会产生良好的结果：因为对象只能通过接口访问，所以我们并不破坏封装性；只要类型一致，运行时刻还可以用一个对象来替代另一个对象；更进一步，因为对象的实现是基于接口写的，所以实现上存在较少的依赖关系。 对象组合对系统设计还有另一个作用，即优先使用对象组合有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控 制的庞然大物。另一方面，基于对象组合的设计会有更多的对象(而有较少的类)，且系统的行为将依赖于对象间的关系而不是被定义在某个类中。