软件工程三要素
方法：完成软件开发的各项任务的技术方法，为软件开发提供 “如何做” 的技术
工具：为运用方法而提供的自动的或半自动的软件工程的支撑环境
过程：为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤，
如何将软件工程方法与软件工具相结合，合理、及时地进行软件开发
Unified Modeling Language UML语言 一般我们用UML中的类图
类图关系如下：
实现关系是指接口及其实现类之间的关系
泛化关系（Generalization）是指对象与对象之间的继承关系
关联关系（Association）是指对象和对象之间的连接，它使一个对象知道另一个对象的属性和方法。
在Java中，关联关系的代码表现形式为一个对象含有另一个对象的引用（关联关系有单向关联和双向关联。 ）
依赖 （Dependency） 关系是一种弱关联关系。依赖关系在Java中的具体代码表现形式为B为A的构造器或方法中的局部变量、
方法或构造器的参数、方法的返回值，或者A调用B的静态方法。
聚合（Aggregation）是关联关系的一种特例，它体现的是整体与部分的拥有关系，即“has a”的关系。
此时整体与部分之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，
也可以为多个整体对象共享，所以聚合关系也常称为共享关系。
组合（Composition）也是关联关系的一种特例，它同样体现整体与部分间的包含关系，
即“contains a”的关系。但此时整体与部分是不可分的，部分也不能给其它整体共享，
作为整体的对象负责部分的对象的生命周期。这种关系比聚合更强，也称为强聚合。
若要出去吹牛的话，第一个要记住这个：共23种设计模式
创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、
责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。如何衡量软件设计质量
首要的标准
满足软件的功能需求
满足软件功能需求的设计并不一定就是好的设计。
好的设计
可读性：软件的设计文档是否轻易被其他程序员理解。可读性差的设计会给大型软件的开发和维护过程带来严重的危害。
可复用性：软件系统的架构、类、组件等单元能否很容易被本项目的其它部分或者其它项目复用。
可扩展性：软件面对需求变化时，功能或性能扩展的难易程度。
可维护性：软件维护（主要是指软件错误的修改、遗漏功能的添加等）的难易程度。
内聚度、耦合度：高内聚，低耦合。
内聚度定义：表示一个应用程序的单个单元所负责的任务数量和多样性。
内聚与单个类或者单个方法单元相关。
好的软件设计应该做到高内聚。
理想状态下，一个代码单元应该负责一个内聚的任务，
也就是说一个任务可以看作是一个逻辑单元。一个方法应该实现一个逻辑操作，一个类应该代表一种类型的实体。
内聚原则背后的主要原因是重用。遵循该规则的另一个优点是，
当一个应用程序的某些方面需要做出改变时，我们能够在相同单元中找到所有相关的部分。
如果一个系统单元只负责一件事情，就说明这个系统单元有很高的内聚度；
如果一个系统单元负责了很多不相关的事情，则说明这个系统单元是内聚度很低。
内聚度的简单判断方法
如果一个方法可以用简单的“动词+名词”的形式来命名，或者如果一个类可以用准确的名词来命名，
那么这样的类或者方法就是内聚度较高的系统单元；反之，如果类或者方法的名字必须包含“和”、
“或”等字样才能准确反映其功能特性的话，这些类或方法的内聚度就一定不高。
耦合度表示类之间关系的紧密程度。
耦合度决定了变更一个应用程序的容易程度。在紧密耦合的类结构中，
更改一个类会导致其它的类也随之需要做出修改。显然，这是我们在类设计时应该避免的，
因为微小的修改会迅速波动影响到整个应用程序。此外，找到需要修改的所有的地方是必须的，
实际上就使得修改变得困难并且耗费时间。而在松散耦合的系统中，我们可以更改一个类，
不需要修改其它类，而应用程序仍然能够正常工作。
|
设计原则名称 |
设计原则简介 |
重要性 |
|
单一职责原则 |
类的职责要单一，不能将太多的职责放在一个类中。 |
★★★★☆ |
|
开闭原则 |
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能。 |
★★★★★ |
|
里氏替换原则 |
在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象。 |
★★★★☆ |
|
依赖倒转原则 |
要针对抽象层编程，而不要针对具体类编程。 |
★★★★★ |
|
接口隔离原则 |
使用多个专门的接口来取代一个统一的接口。 |
★★☆☆☆ |
|
组合/聚合复用原则 |
在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系。 |
★★★★☆ |
|
迪米特法则 |
一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互。 |
★★★☆☆ |