设计可复用软件实体的具体技术

一、软件复用
依据复用成分抽象程度的高低，可以将复用过程划分为如下的复用级别：
(1)代码的复用
包括目标代码的复用和源代码的复用。其中目标代码的复用主要依靠编程语言的编译系统提供的连接、绑定等功能来实现，该复用的级别最低，源代码复用是指在程序设计时，防水墙把—些以前编写的代码直接复制到现在的程序个，但这样往往会导致新旧代码不匹配。因此．这两种复用都不够理想。
(2)设计的复用
设计结果比代码更为抽象，复用时所带要的修改较少，并且不易受环境变化的影响，更有利于软件的复用
(3)分析的复用
它比设计结果具有更高的复用级别，可复用的分析构件是对某个问题域处理一些问题的通用方法，它不容易受设计技术及实现条件的影响，因此复用的可能性更大。

二、类
2.1继承
面向对象的开发语言中自然少不了继承，有了继承，就可以使子类拥有父类的属性和方法，这也是一种复用，甚至可以说是十分重要的一种复用，子类可以不用将某些方法
2.2委托
在java中类直接调用这个类的static方法，类似c语言中的函数，直接调用就行，这样也是一种类的复用。类似Math.sprt()这种方法。

三、API
3.1.概念
一些预先定义的函数，或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而无需访问原码，或理解内部工作机制的细节。
3.2API设计原则
• 小巧：一个类的公共成员尽量少。这样做可以使代码更容易理解、记忆、调试和修改。
• 完整：完整意味着该有的功能都应该有。这一点貌似和小巧有所冲突，但是，如果一个成员函数出现在错误的类中，那么大部分使用者应该都不会找到它。
• 简单清晰：正如其他的设计工作一样，你应该应用这些原则，尽量避免特殊情况。使大部分工作变得简单，特殊的部分也需要考虑但不是本文所关注的。解决特殊问题的原则：如非必要，不要将解决特殊问题的方案影响到通用的情况。
• 观：因每个人的经验和背景的有所差异，因此对直观的判断也会不同。API设计得直观的原则可以理解为：一个经验不足的使用者可以不用使用文档而仅使用代码来理解并使用API。
• 容易记忆：为了使API容易记忆，你应当选择一个一致并准确的命名习惯。使用容易辨别的模式和概念，避免缩写。
• 代码可读性：代码只会写一次，但是却会经常去阅读（调试和修改）。可读的代码也许不再需要重写，但生命周期却贯穿整个产品的生命周期。
• 静态多态：相似的类应当有相似的API。可以使用继承来完成这项工作，即运行时多态特性。但是多态也发生设计阶段。例如，你可以改变一个QProgressBar为QSlider，或者是一个QString为QByteArray。你会发现相识的API使得替换工作变得非常容易，因此这里我们叫它“静态多态”。
静态多态也使得记忆和编程变的更加容易。相关的类使用相似的API通常要比每个类独立的设计API要好得多。
• 可见性：典例：实现或者调用某个函数过程
• 实现某个函数的时候，函数的参数类型本来并没有见过，但通过智能感知提示我们能够了解到这个新 API 并正确取到参数中我们期望得到的信息。
• 调用某个函数的时候，我们需要传入本来并没有见过的参数类型，通过智能感知提示，我们能够知道如何构造或获取这些类型然后正确传进去。
• 调用完某个函数后我们得到了返回值，我们本来并没有见过这个类型，但通过智能感知提示，我们能够学习到这个新的类型，并知道如何正确使用这个返回值。

四、框架：
4.1概念
一组具体类、抽象类、及其之间的连接关系
开发者根据 framework的规约，填充自己的代码进去，形成完整系统。通常通过选择性覆盖来扩展框架;或者程序员可以添加专门的用户代码来提供特定的功能—即定义继承了抽象类祖先操作的具体类 Hook方法，它被应用程序覆盖以扩展框架。Hook方法系统地将应用程序域的接口和行为与应用程序在特定上下文中所需的变体解耦。 控制反转：与库或标准用户应用程序不同，控制流不是由调用者决定的，而是由框架决定的。不可修改的框架代码：在接受用户实现的扩展时，框架代码不应该被修改。换句话说，用户可以扩展框架，但不应修改其代码。
常见的框架类似于spring框架这种，spring框架代码不能修改但是拥有DI,IOC，方便用户创建对象，何时创建对象，交给系统来判断，用户只需要使用对象就行了。
4.2分类
类型也有两种：
白盒复用：源代码可见，可修改和扩展，复制已有代码当正在开发的系统，进行修改
优点：可定制化程度高
缺点： 对其修改增加了软件的复杂度，且需要对其内部充分的了解
黑盒复用：源代码不可见，不能修改，只能通过API接口来使用，无法修改代码
优点：简单清晰
缺点：适应性差