面向对象分析与设计

编写伟大软件的三大步骤：

• 确认你的软件做客户要它做的事。
• 运用基本的OO原则来增加软件的灵活性
• 努力实现可维护，可重用的设计

 

1.需求：

好的需求确保你的系统如预期那样运作。

确认你的需求涵盖了你的所有用例。

运用你的用例找出客户忘记告诉你的事。

你的用例将揭露任何不完整，遗漏的需求，你可能需要将那些需求加进你的系统中。

你的需求将总是随着时间的改变而改变（及成长）。

 

2.分析与设计：

   设计良好的软件容易改变与扩展。

   使用像封装与继承这样的基本OO原则来确保你的软件有灵活性。

   如果设计没有灵活性，就改变它！别与坏设计妥协，即使那是你自己的坏设计，要改就是要改。

   确认你的每一个类都具有内聚性，每一个类都应该聚焦在把一件事情做得很好上来。

   随着软件的设计生命周期的展开要持续努力提高内聚力。

 

3.如何解决大问题：

   聆听客户，找出他们要你构建什么

   用客户理解的语言组合功能列表

   确认你的功能是客户真正想要的东西

   运用用例图创建系统的蓝图。用例是面向细节的，用例图则是比较聚集在整体轮廓上。

   领域分析让你检查你的设计，并是以客户所用的语言。领域分析帮你避免构建不属于你的责任范围内的系统部分。

   将大系统分解成许多较小的部分（模块）

   运用基本的面向对象原则为每一个较小的部分设计程序

 

4.架构

架构是系统的组织结构，包含分解开来的各个部件、它们的连通性，交互机制以及你在系统设计中使用的指导原则与决策。

如何找出哪些是最重要的功能？架构三问：

• 它是系统本质的一部分吗？（系统的本质是指在最基本的层次上系统是什么）
• 这到底是什么意思？（假如你不确定某项功能究竟是什么，该功能可能就很重要）
• 我到底该如何做？（对于很难实现的地方，通常也是重要的地方）

 每当不确定某项功能的意义时，首先得询问客户，该功能的意义为何，然后作共同性分析，最后实现计划。

在架构阶段，你所做的每一件事都应该减少项目的风险。运用共同性分析来构建具有灵活性的软件解法。

 

5.设计原则

设计原则是能被应用到设计或编写程序代码中的工具或技术，让程序代码更可维护，更具灵活性或者更易扩展。

 

• 开闭原则(OCP)：对扩展开放，对修改关闭。也就是说一个类允许通过扩展而改变，但不是以修改现有程序代码的方式进行(如通过继承机制，组合机制)。其实就是封装与抽象化的结合。

 

• 不自我重复原则(DRY)：通过将共同之物抽取出来并置于单一地方来避免重复的程序代码。越没有重复的代码就越没有维护的梦魇。这关系到让系统中每一个信息与行为的片段保存在单一、合理的地方。需求应该只被实现一次，用例不应该有重叠，你的程序代码不应重复它自己，这些都是这个原则的具体表现。

 

• 单一职责原则(SRP):系统里的每一个对象应该具有单一职责，所有对象的服务都应该聚焦在实现该职责上。也就是说每一个类应该只有改变的理由。通过The 类名 方法名（+参数） itself.这种方式不断测试某个方法是不是应该属于该类。

 

• 里氏替换原则(LSP):子类型必须能够替换其基类型。继承必须确保父类型所拥有的特质（属性与方法）对子类型仍然成立，也就是说，当子类型能替换其父类型时，才算真有正确合理的继承关系。

当继承不是好的解决方法时，可以考虑用委托和组合来解决问题。

委托：是将特定工作的责任委派给另一个类或方法。一般用关联关系来实现。假如你想要使用另一个类的功能，但不想改变该功能性，考虑以委托代替继承。

组合：让你使用来自一组其它类的行为，并且可以在运行时切换该行为。使用组合你可以重用来自一个或多个类的行为，特别是来自一个族群的类的行为。你的主要对象完全拥有被组合对象，而且破被组合对象不存在于主要对象之外。

聚合：是当一个类被用作另一个类的一部分时，但仍然可以存在于该类之外。当你想要组合的所有好处，但是也想要在主要对象之外使用破坏草组成对象的行为时，就使用聚合。

 

6.迭代与测试

伟大软件的编写是迭代进行的，先针对整体轮廓操作，接着迭代应用程序的每个片段，直到完成。

• 功能驱动开发：挑出应用程序的特定功能，并且规划、分析及开发该功能，直到完成。
• 用例驱动开发：挑出通过用例的场景，并且编写程序代码以支持通过该用例的完整场景。

 

OO原则：继承，多态，抽象化，封装

1.将变化之物封装起来，通过封装变化之物让你的软件更有灵活性，更容易改变。

2.对接口编码，而不是对实现，让你的软件容易扩展。

3.应用程序中的每一个类只有一个改变的理由。

4.类是关于行为与功能的。

 

行为有变化的时候才考虑创建子类！

大多数的好设计都是通过分析坏设计而来的。不要害怕犯错及改变！

每一次对软件进行改进，试着确认它变得越来越具有内聚性，类的高内聚意味着类之间的低耦合。

你可以将大问题分解成许多功能片段，接着就单独解决每个片段。