▪ 代码可理解性/可读性
可理解性
代码的可读性
例如：
是否遵循命名惯例？
它是自我描述和/或评论很好吗？
事物（例如，课程）是否一次只做一件事或多件事？
这些方法是长还是短，并且可以在一次阅读中理解它们的意图，还是需要进行大量的屏幕盯着和白板分析？
别名：可读性
可读性是指人类读者能够轻松理解源代码的目的，控制流程和操作。
它影响上述质量方面，包括便携性，可用性和最重要的可维护性。
可读性非常重要，因为程序员大部分时间都在阅读，尝试理解和修改现有的源代码，而不是编写新的源代码。
无法读取的代码通常会导致错误，效率低下和代码重复。
▪ 编码规范
名字长度
名称应该是描述性的。 名称越长，可能的描述就越多。
名称也应简明扼要。 名称越长，它的效率就越低。
注释密度（MCOMM％）
MCOMM％= MCOMM / LOC
等宽字体代码
复杂性和LoC
复杂性
复杂的代码不太可能是可以理解的。
代码行（LoC）
方法越长，理解起来就越难。
▪在四个地方使用注释：
标题注释引入了类定义，重要函数，宏定义包，一些其他非平凡模块或整个源代码文件。 对于专有程序，标题注释通常包括版权声明。
介绍性注释描述了类，函数或其他模块的用途和用法。
块注释描述了一组相关语句的目的和策略。
单行/尾随/行尾注释解释单个声明或甚至声明的一部分。
▪ Programing for/with reuse
软件重用是使用现有软件组件实现或更新软件系统的过程。
设计模式
跨应用程序发生的泛型抽象表示为显示抽象和具体对象和交互的设计模式。
基于组件的开发
通过集成符合组件模型标准的组件（对象集合）来开发系统。
应用程序框架
可以调整和扩展以创建应用程序系统的抽象和具体类的集合。
遗留系统包装
可以通过定义一组接口并通过这些接口提供对这些遗留系统的访问来“包装”的传统系统。
面向服务的系统
通过链接可能在外部提供的共享服务来开发系统。
应用产品系列
应用程序类型围绕通用体系结构进行概括，以便可以针对不同客户以不同方式进行调整。
COTS集成
COTS（商业现货，商务现货供应）。 通过集成现有的应用系统来开发系统。
可配置的垂直应用
通用系统的设计使其可以根据特定系统客户的需求进行配置。
程序库
实现常用抽象的类和函数库可供重用。
程序生成器
生成器系统嵌入特定类型的应用程序的知识，并且可以在该域中生成系统或系统片段。
面向方面的软件开发
编译程序时，共享组件将编织到不同位置的应用程序中。
源代码级别：方法，语句等
模块级别：类和接口
库级别：API
Java库
Maven
系统级：框架
▪ Liskov替换原则（LSP）
行为子类型
▪设q（x）是可证明关于类型T的对象x的属性。那么对于S类型的对象y，q（y）应该是可证明的，其中S是T的子类型。
▪Java中编译器强制规则：
子类型可以添加，但不能删除方法
具体类必须实现所有未定义的方法
重写方法必须返回相同的类型或子类型
重写方法必须接受相同的参数类型
覆盖方法可能不会引发其他异常
▪也适用于指定的行为：
相同或更强的不变量
所有方法的相同或更强的后置条件
所有方法的相同或较弱的前提条件
▪ Delegation 委托
委托是指一个对象依赖于另外一个对象的部分功能
显式委派：将发送对象传递给接收对象
隐式委派：通过语言的成员查找规则
委托可看做是在实体之间共享代码和数据的低层机制
委派与继承
继承：通过新操作扩展基类或覆盖操作。
委托：捕获操作并将其发送到另一个对象。
许多设计模式使用继承和委派的组合。
小结：对象之间的联系
继承/泛化inheritance：一般与特殊的关系——is a kind of
组合composition：部分与整体的关系，彼此不可分——is part of
聚合aggregation：部分与整体的关系，但彼此可分——owns a
关联association：对象之间的长期静态联系——has a
依赖dependence：对象之间的动态的、临时的通信联系——use a
类间联系的强度：继承>>> 组合>> 聚合>> 关联>>> 依赖
▪ 接口的组合
▪ 白盒、黑盒框架的原理与实现
Whitebox和Blackbox框架
Whitebox框架
通过子类化和重写方法进行扩展
通用设计模式：模板方法
子类有主要方法但控制框架
Blackbox框架
通过实现插件接口进行扩展
共同设计模式：战略，观察员
插件加载机制加载插件并控制框架
Whitebox vs. Blackbox框架
Whitebox框架使用子类
允许扩展每个非私有方法
需要了解超类的实现
一次只能扩展一个
汇编在一起
通常所谓的开发者框架
Blackbox框架使用组合
允许扩展界面中公开的功能
只需要了解界面
多个插件
通常提供更多的模块化
可以单独部署（.jar，.dll，…）
通常所谓的最终用户框架，平台
▪ 设计模式adapter、decorator、façade、strategy、template、iterator/iterable
Adapter Pattern 适配器模式
目标：对旧的不兼容组件进行包装，在新系统中使用旧的组件
适配器模式
两种类型的适配器设计模式
继承
委托
Decorator 装饰器模式
方案: 实现一个通用接口作为要扩展的对象，将主要功能委托给基础对象(stack)，然后添加功能(undo,secure,…)。
接口：定义装饰物执行的公共操作
起始对象，在其基础上增加功能(装饰)，将通用的方法放到此对象中。
装饰者与继承
▪Decorator在运行时编写功能
继承在编译时组成功能
▪装饰器由多个协作对象组成
继承产生一个明确类型的对象
▪可以混合搭配多种装饰品
多重继承在概念上很难
Façade 外观模式
调用者需要一个简化的接口来调用复杂系统的整体功能。
提供更高层次的接口来使子系统易于使用。
Strategy 整体地替换算法
针对特定任务存在多种算法，调用者需要根据上下文环境动态的选择和切换。
示例：对客户列表进行排序（冒泡排序，合并排序，快速排序）
定义一个算法的接口，每个算法用一个类来实现，客户端针对接口编写程序。
Template Method 模板方法
不同的客户端具有相同的算法步骤，但是每个步骤的具体实现不同。
在父类中定义通用逻辑和各步骤的抽象方法声明。
子类中进行各步骤的具体实现。
在父类声明一个通用逻辑。
模板模式用继承+重写的方式实现算法的不同部分。
策略模式用委托机制实现不同完整算法的调用(接口+多态)
Iterator 迭代模式
问题：客户端需要以统一的、与元素类型无关的方式访问容器中的所有元素
