OOA/D学习笔记 1

OOA/D(Object-Oriented Analysis and Design)

【引用】"拥有一把锤子未必能成为建筑师",了解面向对象编程语言是创建对象系统必要但并不充分的第一步,了解如何"用对象进行思考"同样重要.

OOA/D中最关键、最基本的能力是熟练的为软件组件分配职责。因为分配职责是必须要执行的一项活动，并且它对软件组件的健壮性、可维护性和可重用性具有重要影响。

Analysis：强调的是对问题和需求的调查研究，而不是解决方案。

Design：强调的是满足需求的概念上的解决方案，而不是其实现。

他们可以概括为：做正确的事（Analysis）和正确地做事（Design）

在OOA的过程中，强调的是在问题域内发现和描述对象和概念。

在OOD的过程中，强调的是定义软件对象和这些软件对象如何协作来满足需求。

最后在实现或面向对象编程过程中会实现设计对象。

什么是UML？

【引用】"统一建模语言(UML)是说明、可视化、构造和文档化软件系统工件的语言，也可用于业务建模和其他非软件系统" 

UML是Unified Modeling Language的首字母缩写词，从字面来理解它是一种统一建模语言。也就是说，它只是一种语言，一种用来对构建的模型进行表达的可视化语言。尽管UML常常用来建模OO软件系统，但是UML它本身并不是一种软件建模的方法论，它仅仅提供可以用于创建模型的一种可视化语法。我们在构建OO软件模型时常用的方法论应该是UP（Unified Process，统一过程），它告诉我们为了建模一个软件系统所需要利用、执行或者创建的工作者（worker）、活动（activity）和制品（artifact）。那么，UML名称中的"U"就是Unified（统一），它到底统一了什么呢？UML统一了几种不同领域。

• 开发生命期——UML提供用于从需求分析工程到实现，贯穿整个软件开发生命期的可视化建模语法。

• 应用领域——UML已被用于从关键实时嵌入系统到管理决策支持系统中任何事务的建模

• 实现语言和平台——UML中立于语言和平台。

• 开发过程——尽管UP及其变体可能是OO系统的首选开发过程，UML能够支持很多其他软件工程过程。

• 它本身内部概念——UML在其内部概念的一个小集合的应用上，勇于尝试保持一致和统一

  OOD的原则
  
  良好的设计，就是系统容易理解、容易改变、容易重用。
  
  
  设计的“异味”
  
• 僵化性（Rigidity）——系统很难改变，因为改动一处，就不得不改动其他地方，甚至引起无休止的连锁反应
• 易碎性（Fragility）——改变某个部分，会破坏很多完全无关的部分
• 固化性（Immobility）——很难将系统分解成可供其他系统重用的组件
• 粘稠性（Viscosity）——永远走不出编辑-编译-测试这一无休止的循环
• 不必要的复杂性（Needless Complexity）——很多非常聪明的代码结构目前还不需要，但有一天可能用上
• 不必要的重复性（Needless Repetition）——代码看上去是两个叫剪切和粘贴的程序员写的
• 不透明性（Opacity）——

      UML图可以帮助我们，通过检查图之间的依赖关系，可以找出其中很多异味。那么应该怎么样来规定依赖关系呢？

      单一职责原则（The Single Responsibility Principle - SRP）

一个类只能因为一个原因而改变
在UML图中，找一找那些与多个主题域存在依赖关系的类。

      开放-封闭原则（The Open-Close Principle - OCP）

软件实体（类、模块、方法等）应该允许扩展，不许修改

应该可在不改变模块本身的情况下改变模块周围的环境

      里斯科夫替换原则（The Liskov Subsitution Principle - LSP）

子类型必须能够替代它们的基类型

LSP指出，基类用户不必为了使用派生类而做任何特殊的事情。确切的说，它们不应该需要使用instanceof，也不必向下转型。实际上，它们根本不需要了解派生类，甚至不必知道是否存在派生类。

      依赖关系倒置原则（The Dependency Inversion Principle - DIP）

A.上层模块应该不依赖于下层模块。它们都依赖于抽象。
B.抽象应该不依赖于细节。细节应该依赖于抽象。
不要依赖易变的具体类。从UML的角度看，顺着UML图中的每个箭头，检查箭头的顶端指向的是否是一个接口或抽象类。如果不是，而且指向的具体类是会改变的，那么就违反了DIP。

      接口隔离原则（The Interface Segregation Principle - ISP）

客户端不应该依赖于自己不用的方法。

遵循一个简单的规则——为使用者提供只包含了它们要用到的方法的接口——就可以保护使用者被不用的方法影响

      运用这些原则的最好方式是有的放矢，而不是”主动出击“。