程序设计方法与艺术复习提纲

程序设计方法与艺术
1、软件的演变过程及特点、理论学家的观点、现实是什么
软件的演变过程:机器语言、FORTRAN语言、数据库语言、智能语言、可视化的面向对象语言
欧洲派：编程是一门数学味儿很浓的工程学科、美国派：编程序很简单。

现实是：1、软件工程也不要求所有程序员都是受过高等教育的科学家。

2、程序员可以无绪也能产生可靠的软件系统。

无绪是指程序员不需要深入了解很多内容，就可以写出好的代码3 找到一种编码实践方法，让开发人员不用深入了解所有事情。

2、大型软件特点、开发与设计方法、推土机方式
现在大型软件特点：
1、基于大型组件进行组装
2、先安装一个可靠又低廉的操作系统
3、安装Web服务器和数据库服务器
4、
应用程序编写简单5、系统复杂、完全了解整个系统的全部内容很少。

6、无绪状态软件开发
更好的无绪：推土机方式。

推土机方式的系统:需要什么安装什么
1 、需要什么安装什么: 数据库、Java平台、应用服务器加内存
2 、系统越来越大，但效率也很高
3 、Web 系统上，有大量的系统是采用这种推土机方式建立。

3、软件开发理论上的目标和要求，软件开发无绪
真实、漂亮和优雅
4、分布式开发方法、特点、开源代码开发及特点
无绪的模型、组件模块重用、开发周期短、用API来完成接口调用、多类库组成
分布式开发特点:整个程序的源代码多人控制、产品的开发进度无法全面掌控、全面掌控往往只是一种理想状态、版本自由选择
开源代码的特点：免费、使用和获取方便、有充足的资源使用、安全有保障
5、模块化应用程序开发及特点、版本管理相关内容
多版本同时使用
6、API及使用特点，不同软件版本的特点
一个API是一堆类以及类方法和字段（属性）的集合。

对所有公开成员访问，只需要访问相应的名称；对非公开成员访问，一般使用反射技术来创建对象时，不需要知道具体类型，只需要的话字符串的方式传入类的全名即可创建一个实例对象。

反射是直接读入dll或者对应的库，反射机制是取出模块中所有的中间语言代码
7、部署图及应用
部署图对面向对象系统的物理方面建模,描述系统运行时节点、构件实例及其对象的配置。

8、API构件模快及特点，如何检查API的质量
构件模块：包括共享类库、框架、预先定义的应用程序框架、及上述的组合。

每个API完全正确，程序集成工作就简单，不存在调试、阅读代码、打补丁和如何设计，是“无绪”的编程。

可理解性、一致性、可见性、简单任务应该有简单方案、保护投资
9、类成员访问涉及模块内部相关问题
公开成员：对所有公共成员访问，只需要访问相应的名称。

非公开成员：一般使用反射技术来创建对象时，不需要知道具体类型，只需要的话字符串的方式传入类的全名即可创建一个实例对象。

10、反射机制及作用，环境变量及作用
反射机制是取出模块中所有的中间语言代码。

作用：程序集设计者本身在程序集发布后由于某些需求想调用原先的私有方法，进行某些操作；程序集的使用者恶意的使用私有成员作一些本身out of scope by design 的事情。

环境变量可以控制程序
11、软件协议及相关问题
协议是针对文本内容的API。

它们用来定义网络传送中的信息格式，所以非常重要。

协议访问控制问题：对于一个对外开放的套接字来说，访问是没办法进行控制的。

另一个问题是因使用网络协议而被放大，每个网络协议会有多种客房段，协议有多个版本和程序进行交互，且这种多样性还会不断扩散。

不一致问题：服务器上的Subversion软件版本与客户端计算机上所使用的版本不一致。

12、软件版本如何控制，不同版本的特点，软件向后兼容的相关内容
放弃老版本、修正老版本、重写系统
向后兼容：源代码兼容、二进制兼容、功能兼容
13、面向用例特点
面向用例是对API用法的描述，使API尽量完美
14、如何理解API内容公开与隐蔽
API公开的内容越少越好，有必要才公开。

公开大量不必要的内容会使API无法保持兼容性
15、虚拟机内容及相关特点及作用
虚拟机首先解释执行类文件中的内容，然后监控程序的执行情况。

解释执行、动态编译速度快
16、工厂方法内容及作用
灵活性高、多态性（支持参数化返回类型），优于构造函数
17、继承的特技及其优缺点，类成员的访问方式、SET,GET方法的特点
能不继承就不继承，减少外部的使用方式、
利用SET/GET方法访问内部字段
18、面向接口及面向实现进行编程，方法的移去、添加的相关问题
借口是用来公开给使用者的说明部分，实现是累内部的具体实现过程。

移去：对于源代码和二进制来讲，移除一个抽象的proteced方法是可以兼容的。

添加：(1) 尽量少用字段、（2）添加一个抽象方法可能不向后兼容、(3)避免继承类添加新抽象方法、（4）不要在接口中添加一个非抽象方法
19、J ava中接口和类的区别、抽象类及作用
接口允许多继承，类只能有一个直接父类
抽象类可以包含static方法
20、大型软件的基本构成、模块化程序、模块化设计的类型
大型软件的基本构成：独立的块、组件、模块或者插件
模块化程序：由不同模块构成的，一个模块是一组类的集合。

模块化组成：每个部件都是独立的，并提供定义良好的对外接口供外部调用
类型：最简单模块形式（完全封闭）、功能扩展
21、组件定位和交互及相关内容
组件定位和交互是为了实现各部分的松耦合，模块调用、用代码注册配置
22、类的注册配置相关内容、组件注入及相关内容
减少多次注册避免系统启动过慢、利用声明绑定服务不需要写具体代码
一般注入：只要选择必要类库
Spring注入：对Spring注入方案进行一些扩展
常见组件注入：以注册的方式将服务实现放到缓存池中
LOOKUP注入：能准确部署各种实现，只要调用LOOKUP提供的方法
23、真正Lookup机制相关内容及作用，优缺点
LOOKUP可以有多个实例，每个实例都有自己的缓存池
LOOKUP就像一个事件总线、LOOKUP使用adaptable模式管理各种注入
24、A PI不同目标用户群体内容、SPI相关内容
区分插件与客户端：插件是一种遵循一定规范的应用程序接口编写出来的程序。

客户端程序，一种以客户为导向的价值观，整合及管理在客户界面的所有要素。

API与SPI
SPI：service provider interface
SPI不能添加新内容、设计SPI时用接口
25、软件测试相关内容及作用，软件编程，兼容性编程归范的优缺点
测试基本的策略都与Mock对象有关。

在提供一个普通的API的同时，还要提供一个测试API
26、A PI下相互协作，API一致性问题
API不是单独存在的。

光靠它们自己可做不什么有意义的事情；一定要被调用才能完成特定的功能。

只有少数的API可以独自运行，无须任何上下文环境。

必须了解如何正确地使用第三方API，才不会造成意想不到的后果。

一致性问题：在设计模块化类库的时候，只需要定义API对外公开，而其他单独的模块会根据这些API来提供具体的实现，如果是这样，那么表面要验证一个API的功能，其实要验证的却是它背后的所有具体实现。

出现问题时，也不是说只需要修正当前类库里面的代码就能搞定的，还有可能要强制要求该类库所有的第三方开发商都要修正相关代码中的问题。

解决：编写TCK、避免方法被覆盖，让相应的类变成FINAL类
27、大型软件的代理和组合
使用代理加上组合，避免使用继承，因为继承为一个类留下了太多的后门，采用组合技术可以正地设计API，让每一个API类都有明确的功能以及清晰的定义，不仅清楚而且优雅地为API不同类型的用户分离出相应的接口，而且该解决方案不会使其变得更加复杂
28、A PI具体运行时的一些内容、程序的并发问题
不要冒险、注意可靠性与无绪，提高开发时的透明度。

对于存在并发的程序和系统来说，最难的地方就在于如何保证并发正确运行。

29、同步和死锁
描述线程模型、使用getter/setter方法访问私有字段时添加assert以保证线程安全、不要在持有锁的情况下调用外部代码。

30、日志的高级用途
只关注对外暴露功能的地方，在测试用例执行的过程中收集信息，如果任何一个测试方法出现了问题，在程序执行过程中产生的所有日志记录都会包含在错误报告中，可以从日志中的信息中得到分析结果，如果说无法从这两个日志文件得到分析结果的话，有两种可能。

首先是日志文件没有足够的信息，或者是日志文件中记录的信息可能太粗略，无法就问题发生的原因提供明确的信息
31、声明式编程的优缺点
能够从比较高的层次来定义一些操作，然后由其他人执行相应的操作，与普通编程相比，后者需要从细节上定义每一处操作。

一致性并不是声明式编程带来的唯一好处，有效性是另一个优点，还有抽象性。

32、A PI的漂亮与优雅
在设计API时追求漂亮，一个直接的结果是必须保留很多本该弃用的内容，对于开发者来说，为了漂亮往往会选择从API中移除一部分内容，而不是弃用这部分的内容。

优雅固然好，但是这并不是API最重要的特质。

往往项目的出资人更关心的是尽快地将产品推出市场并且要控制成本，还有就是使用的技术酷不酷。

33、理解API的简单与复杂相关内容
在设计API的时候，让复杂功能尽可能实现的同时，让简单的功能尽量地易用。

34、A PI的性能要求，API的兼容性问题
性能往往是破坏向后兼容性的主要原因，如果API设计得不好，那么用户在使用API时会碰到很多性能的问题，如在调研方法时，代码的执行速度非常慢，亦或在执行过程中会创建很多不必要的对象。

在设计API时，也不应该单单为了性能过度优化而违背了API的设计原则，要谨防不成熟的优化。

在对类库做整合时，无论是最终用户还是应用程序装配者，都极其以来于向后兼容性。

努力做到向后兼容是可取的，也是必要的。

但是有时候考虑到实际的情况，100%的兼容往往是实现不了的。

99%的向后兼容性意味着在修复问题的同时，要严谨地考虑其肯呢过带来的不兼容性问题，往往要在两者之间取得一个平衡。

35、A PI的对称及相关内容
对称指API设计时其使用方式应该比较一致，减少学习成本。

对称也有助于提高API的透明度。

36、A PI开发与维护阶段相关内容、方式
一旦API的用户数量大幅增加，就不能随意对API进行修改，开发进入维护阶段。

最重要目标就是保持向后兼容性，要避免对公开的类、方法和功能进行移除、清理或者大的重构。

37、理解API的漂亮与正确性
不要为了漂亮保留很多本该弃用的内容，不要为了正确性牺牲易用性。

38、版本的稳定性与版本的改进
所谓的稳定并不是说让API一成不变，它更多的是对API维护态度上的一个要求。

一个稳定的API也是会产生变化的，会逐渐演进。

改进的时候一定要选择哪种不会伤害现有用户的方式，如果伤害不可避免的话，至少也要选择伤害最小的那种。

要注意保持向后的兼容。

39、怎样降低版本的维护代价
如果创建API的方式正确，那么维护它的成本并不比维护普通代码来得高。

而且可以利用自动化测试降到成本，如果对一个API的评审和设计都做得很好的话，那么对它的维护就是小菜一碟，维护的代价低。