软件框架设计的艺术思维导图
简单介绍软件框架设计的艺术
树图思维导图提供 软件框架设计的艺术思维导图 在线思维导图免费制作，点击“编辑”按钮，可对 软件框架设计的艺术思维导图 进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：9e3ca62a2d803246d6fbcd68ece72715
思维导图大纲
软件框架设计的艺术思维导图模板大纲
序言
“API一旦发布，便于我们永恒共存”
想要将知识传授给其他人的时候，就会因为他们没有类似于我们的经验，也就很难说服他们接受我们的知识
理论与理由
”艺术“还是”工程“
API的重要独特性：一致性
组内如何一致？
合作无间
共同的愿景
方法论
理性主义
经验主义
无绪
深层理解
掌握某种事物背后的原则、规律
大多数时候”浅层理解“已经足够
针对性无绪（selective cluelessness）
某些内如需要深入了解
浅层理解
对某种事物的了解程度只限于掌握使用方法即可
应用程序开发的无绪原则
尽量让最终负责集成的相关人员不需要深入了解系统也可以把集成工作做好
对象：人
评价API好坏的标准
what？
方法、类、字段签名
行为
判断兼容性最重要的方式是”正常运行“，但这一点却是由内部具体实现决定的
null返回值
国际化
文件（unix管道）
环境变量和命令行选型
文本信息（toString）
协议
Quality
一致性
降低学习曲线
保持兼容
可见性
用户不关心具体的类
提供”入口“，以便找到需要的解决方案
基于实际或预期的目标与任务
简单的任务应该有简单的方案
普通的使用者
扩展的使用者
保护投资
多为用户考虑
可理解性
设计人员和开发人员之间交流的途径
范例的重要性
Why？
我们希望能够将大块的构建模块”无绪“的集合成应用程序
不断变化的目标
面向用例的重要性
场景
你应该先做这件事，然后再做那件事就可以了
用例
我应该怎么做
向后兼容
源代码兼容
功能兼容
容易被遗漏
态度，“好老板”不会抱怨客户
二进制兼容
设计实战
只公开你要公开的内容
添加容易，移除困难
方法优于字段
除了static和final声明的基本类型、string常量、枚举和不变对象外，其他字段都不应该被公开
工厂方法优于函数
工厂方法返回值不一定是声明类型的实例，可以是子类的实例
每次返回的对象也不一定是新建的对象，可以将其缓存
同步控制，对创建对象前后的代码进行统一处理
让所有内容不可更改
如不希望拥有子类，就应该让其不可被继承
避免滥用setter方法
如无必要，绝不要在正式的API中声明setter方法
setEnable
可能上下文敏感
isEnable判断，使setEnable失去意义
尽可能通过友元方法来公开功能
java默认的package访问方式，内部类
赋予对象创建者更多权利
访问权限
避免暴漏深层次继承
代码复用
功能复用
“继承”不是用来改变具体的行为，而是用来添加一些额外的动作
如果去继承一个类，只是为了切换某些方法的执行路径，那么这种做法应予以避免
建议：避免深层次继承，定义程序接口，并让用户来实现这些接口
发布第一个版本时，移除不必要的内容
面向接口而非实现进行编程
抽象定义（接口）与实现分离
合作
向API用户讲清楚：使用APi时，应该遵循正确的原则。如果需要使用一个API就要遵守API的原则，不要破坏
清楚的说明API的需求，定义相应的用例，帮助API设计者实现这样的API
protected方法不可移除，导致子类修改
在接口中增加抽象方法，会强迫其非抽象子类实现该方法
模块化架构
面向对象并不能避免意大利面条式的编程
模块化架构将规范与实现分离
在规范所在的模块中，至少会有一个小的“入口”
依赖注入
Spring
Netbean lookup
扩展
模块化的目的：实现各组成部分的松耦合
设计API时要区分其目标用户群
SPI
Service Provider Interface
可以移除但不可增加
供其他人扩展API功能
接口
避免两者混用
合理分解API
API
NetBeans的分类
核心API
支持API
核心SPI
支持SPI
根据用户群体的不同需求来组织你的API结构
SPI
API
可以添加但不能移除
供他人调用来完成某些功能
final类
内聚，自包含
牢记可测试性
测试代码是规范的一部分
好工具让API设计更简单
向导
项目的第一目标快速推向市场
NetBeans中每一项重要的技术都有一个相应的向导来建立初始的基础框架
兼容性测试套件
面向SPI用户和API实现者
让客户尽快的上手
Mock对象
为API提供Mock对象
与其他API协作
只暴露抽象内容
暴露的越多，演进的余地就越小
强化API一致性
代理和组合
避免API的误用
所有的层次之间都需要保持一致性。
谨慎使用第三方API
包装模式
API具体运行时的一些内容
”臭名远扬“—与其抱怨用户，不如改变自己的态度
同步与死锁
正确且恰当的描述其线程模型
Java Monitors中的陷阱
继承影响synchronized
对于公开的API，不能将对外方法申明为同步
处处陷阱的Java同步与死锁
”保卫者“——自动化测试
日常生活
现实生活充满了变化因素，理论的东西不可能一成不变的用在生活中。不仅要知道哪些事情可行，哪些事情不可行，还要知道如何运作才能可行
极端意见有害无益
API必须
是漂亮的
是正确的
如果为了正确性而牺牲了易用性，那么可能会引发更多的问题
尽量简单
是高性能的
绝对兼容
是对称的
API设计中的矛盾
安全部门
飞机安检
开发人员抱怨的事项总是不断，如评审、编程规范，等等。
少数派报告
自相矛盾
Wiki定义：“同时相信两种互相矛盾的观点，而没有意识到两者是矛盾的”
改进API
利用竞赛游戏来改进API设计技巧
沪公网安备 31011502019485号
上海工商