About-JavaOOAD

软件工程三要素

方法：完成软件开发的各项任务的技术方法，为软件开发提供 “如何做” 的技术

 

工具：为运用方法而提供的自动的或半自动的软件工程的支撑环境

 

过程：为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤，

如何将软件工程方法与软件工具相结合，合理、及时地进行软件开发

Unified Modeling Language UML语言  一般我们用UML中的类图

类图关系如下：

实现关系是指接口及其实现类之间的关系

泛化关系（Generalization）是指对象与对象之间的继承关系

关联关系（Association）是指对象和对象之间的连接，它使一个对象知道另一个对象的属性和方法。

在Java中，关联关系的代码表现形式为一个对象含有另一个对象的引用（关联关系有单向关联和双向关联。 ）

依赖 （Dependency） 关系是一种弱关联关系。依赖关系在Java中的具体代码表现形式为B为A的构造器或方法中的局部变量、

方法或构造器的参数、方法的返回值，或者A调用B的静态方法。

 

聚合（Aggregation）是关联关系的一种特例，它体现的是整体与部分的拥有关系，即“has a”的关系。

此时整体与部分之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，

也可以为多个整体对象共享，所以聚合关系也常称为共享关系。

 

组合（Composition）也是关联关系的一种特例，它同样体现整体与部分间的包含关系，

即“contains a”的关系。但此时整体与部分是不可分的，部分也不能给其它整体共享，

作为整体的对象负责部分的对象的生命周期。这种关系比聚合更强，也称为强聚合。

 

若要出去吹牛的话，第一个要记住这个：共23种设计模式

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、

责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

其实还有两类：并发型模式和线程池模式。

 

如何衡量软件设计质量

首要的标准

满足软件的功能需求

满足软件功能需求的设计并不一定就是好的设计。

好的设计

可读性：软件的设计文档是否轻易被其他程序员理解。可读性差的设计会给大型软件的开发和维护过程带来严重的危害。

可复用性：软件系统的架构、类、组件等单元能否很容易被本项目的其它部分或者其它项目复用。

可扩展性：软件面对需求变化时，功能或性能扩展的难易程度。

可维护性：软件维护（主要是指软件错误的修改、遗漏功能的添加等）的难易程度。

内聚度、耦合度：高内聚，低耦合。

 

内聚度定义：表示一个应用程序的单个单元所负责的任务数量和多样性。

内聚与单个类或者单个方法单元相关。

好的软件设计应该做到高内聚。

理想状态下，一个代码单元应该负责一个内聚的任务，

也就是说一个任务可以看作是一个逻辑单元。一个方法应该实现一个逻辑操作，一个类应该代表一种类型的实体。

内聚原则背后的主要原因是重用。遵循该规则的另一个优点是，

当一个应用程序的某些方面需要做出改变时，我们能够在相同单元中找到所有相关的部分。

如果一个系统单元只负责一件事情，就说明这个系统单元有很高的内聚度；

如果一个系统单元负责了很多不相关的事情，则说明这个系统单元是内聚度很低。

内聚度的简单判断方法

如果一个方法可以用简单的“动词+名词”的形式来命名，或者如果一个类可以用准确的名词来命名，

那么这样的类或者方法就是内聚度较高的系统单元；反之，如果类或者方法的名字必须包含“和”、

“或”等字样才能准确反映其功能特性的话，这些类或方法的内聚度就一定不高。

 

耦合度表示类之间关系的紧密程度。

耦合度决定了变更一个应用程序的容易程度。在紧密耦合的类结构中，

更改一个类会导致其它的类也随之需要做出修改。显然，这是我们在类设计时应该避免的，

因为微小的修改会迅速波动影响到整个应用程序。此外，找到需要修改的所有的地方是必须的，

实际上就使得修改变得困难并且耗费时间。而在松散耦合的系统中，我们可以更改一个类，

不需要修改其它类，而应用程序仍然能够正常工作。

 

设计原则名称	设计原则简介	重要性
单一职责原则	类的职责要单一，不能将太多的职责放在一个类中。	★★★★☆
开闭原则	软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能。	★★★★★
里氏替换原则	在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象。	★★★★☆
依赖倒转原则	要针对抽象层编程，而不要针对具体类编程。	★★★★★
接口隔离原则	使用多个专门的接口来取代一个统一的接口。	★★☆☆☆
组合/聚合复用原则	在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系。	★★★★☆
迪米特法则	一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互。	★★★☆☆