软件框架设计的艺术----读书总结 (2)

软件框架设计的艺术----读书总结

第一步先确认什么才叫好。

很多人认为所谓的API,不过是类和方法。但是这是比较片面的。

强调一点, 我们为什么需要开发好的API:我们希望能够将大块的构建模块,”无绪“地集合成应用程序。

那么如何评价一个API的质量: 漂亮? 但是评价漂亮的标准是很主观的。我们应该设计易于使用、广为接受且富有成效的API。我们可以有一下几个方面来衡量一个API的好坏。

可理解性: 每个人的世界观都会限制自己d视野,所以对于一个优秀的API来说,他涉及的概念都要在用户的可理解范围之内, 即使有新的概念也应该是渐进式的。

一致性: 向下维持兼容

可见性: 最好提供一个入口用来作为用户API的起点。 为什么大家都喜欢开源,因为开源很多东西网上可以直接拷贝。

简单的任务应该有简单的方案: 所以API应该是分层的。

保护投资: 善待API的用户。 尽量想办法让API漂亮点。如方法名,如结构等。 在发布第一版之前这些都是非常合适的。但是发完第一版以后我们要保证我吗的代码改动不会影响正在运行的代码了。

实现API的步骤

第二步弄清楚写API的步骤

写一个API有三个步骤:用例, 场景, 文档。

一个用例就是一种用法的描述,他指出用户可能要面临的问题,而这个问题不是一个具体的问题,而是很多问题的抽象。

举个例子

用例: 设计一个数据库管理器,他的功能是注册JDBC驱动。

场景:对用例的回答。我们把API要描述的每一个功能下列出来:

注册有一个JDBC可以写一个能够描述驱动的XML, 有格式

这个XML放置在DataBase/JDBCDrivers目录下

用URL来表示驱动地址

注意一些设计原则

软件框架设计的艺术----读书总结

第三步 学习一些设计原则和通用方法

只公开你要公开的内容

面向接口而非实现进行编程

模块化架构

声明式编程

只公开你要公开的内容

软件框架设计的艺术----读书总结

我们所设计的API都会被可能误用。几乎所有的API设计者都会有这样的共识:一个人API设计的时间越长,他设计的API公开的内容会越少。

设计API的几种方法:

1. 方法优于字段

这个不用说了。 geter setter。 这样做会有很多改变的余地。 如计算、转换、校验、覆盖

2.工厂方法优于构造函数

工厂方法会带来很大的灵活性,三个好处:

返回不一定是声明的类型可以是子类

构造的对象可以被缓存

同步的控制。 可以都构造对象前后的代码进行控制。

3. 让所有的内容都不可改变

通常情况下, 在设计一个类的时候,如果不考虑让拥有子类,那就不应该让这个类被继承。 用final 来修饰。 还有些其他方案来: 不公开构造函数转而提供工厂方法。把大部分方法变为final或者private

4. 避免滥用setter方法

一个宝贵的教训: 如无必要,绝对不要再正式的API中声明setter方法。

5. 尽可能通过友元的方式来公开功能

在java中,所谓的友元就是用默认的package方式访问,即允许同一个包内的代码进行访问。

有个实际的例子

6. 赋予对象创建者更多的权利 7. 避免暴露深层次继承

避免深层次的继承,定义程序的接口,并让用户来实现这些接口。 如果一个类继承了某个类或者接口,那么就可以作为响应的类或接口被使用。

如在swing中, frame间接继承了compoment,这样就表示所有使用compoment的地方,都可以使用frame. 实际上frame继承 compoment是为了复用compoment的代码。这是一种典型的面向对象的复用的误用。 所以如果发现继承提醒超过2层,一定要想清楚“我是在设计API还是在复用代码”,如果是后者,则做好子类化准备。

面向接口而非实现进行编程

软件框架设计的艺术----读书总结

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zgzxwj.html