Head First OO&A 学习笔记-CSDN博客

本文链接：https://blog.csdn.net/iteye_6908/article/details/81966614

Head First Object-Oriented Analysis & Design

Head first 一直秉持着在程序书里面乱加图片乱涂乱画的风格，这种风格其实真的可以让人看书看的更快，虽然这段时间项目上比较忙，但是在只看了四五次的情况下就已经把他看完了。确实看这种书有一种看小说的感觉，停不下来似的。之前不管是在学校里还是在公司项目上，对OO也有过一定的认识，但很多时候自己正真时间的时候却不自觉地的用不够OO的方式去分析问题，解决问题，读了本书之后希望之后的实践能多用OO的方式，毕竟书看了只是有个架构，实践多了，才能正真丰满起来。

1. 良好应用程序的基石

如何真正写出伟大的软件?书中一直以这个问题来引导读者。继而给出伟大软件的简易三步骤：

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

2. 收集需求

跟我们现在项目的情况一样，每个项目总是以需求收集开始，因为我们后面需要做的事情全都是想让客户满意。这也是上面提到的编写伟大软件的第一个步骤，确保它能完成客户要它做的事。

需求是系统为了真确运作所必须做的事。
需求最初通常来自客户。
在需求的基础上，我们使用用例来详细描述系统应该做什么。
对于系统需要完成的每一个目标，你至少会有一个用例。
确保所有用例皆可行的需求列表是一组好的需求。
你的系统必须运作在真是的世界里，而不只是在你预期的情况中。

3. 需求变更

正如我们公司的价值观之一，拥抱变化，软件行业，只有一样东西是永远不会改变的，那就是“变化”。变化是每个项目每个系统，都必然存在的。

需求总是随着项目的进行而改变。
当需求变更时，你的系统必须随之演变进以处理新的需求。
在需求变更的过程中，我们需要做到，避免重复的代码给后面的维护工作带来很多重复的工作量很很大的项目风险。所以，这里牵涉到一个非常重要的OO原则：将变化之物封装起来。 在变化再次来临的时候，你只要修改一个地方就可以搞定。

4. 分析
我们的软件最终还是要运行到真实的环境中的，所以我们必须分析我们的程序，让它能够更好的在真实的环境中起作用。

通过编写用例的形式来让自己、你的经理、你的客户以及其他的工程师理解。
每个用例应该只聚焦于一个客户目标。假如有多个目标，你就需要编写多个用例。
通过画类图来简单展示你的系统以及它的程序代码构想。
通过文本分析 可以帮助我们确定我们的类图。用例里的名词是系统类候选者，而动词是系统的类上的方法候选者。

5. 良好的设计 = 灵活的软件
在改变不可避免的时候，分析我们的设计并给出一些更合理，更灵活的方式来实现，使我们的程序更具有复原力。

通过UML来帮助我们分析。
设计良好的软件容易改变与扩展。
使用像封装与继承这样的基本OO原则 来确保你的软件有灵活性。并且坚持另外一个OO原则：对接口编程，而不是对实现。
如果设计没有灵活性，就改变它！别与坏设计拖鞋。
确认每一个类都具有内聚性，每一个类就应该聚焦在把一件事情做得很好上。这里涉及到另外一个OO原则：应用程序的每一个类只有一个理由改变。
随着软件的设计生命周期展开，需要持续女里提高内聚力。
类是关于行为与功能的。

6. 解决大问题

往往我们所遇到的问题，和我们需要编写的程序都不是一个小小的问题，它往往包含了很多东西，我们需要将这些大问题，分割成一些我们能解决的小问题来解决，就像上面提到的那些方式。

就像在较小的项目中那样，从手机功能与需求开始进行大项目。
运用用例图创建系统的蓝图。
用例是面向细节的，而用例图这是比较聚焦在整个轮廓上。
领域分析：用客户理解的语言表示系统。
当你解决了所有的小问题，你的大问题也就已经解决了。

7. 架构
正如上面所说的，我们在解决大问题的时候将它分解成很多小的问题。其实这会面临很多问题，比如说从哪里着手做这些小问题，或者这个部分与那个部分之间的关系是什么，再比如怎么将这些小的模块拼凑到一起。这个时候就要发挥架构的力量了。

架构帮你将所有的图形、谋划以及功能列表转化为井然有序的应用程序。
注意，系统中对项目最重要的功能时在架构上重要的。
在架构阶段，你所做的每一件事情都是应该以减少项目风险为目的。
在整个项目过程中都需要持续的问一个问题：这会减小项目风险么。
有时候，编写伟大的程序代码的最佳方式，是在允许的情况下降程序代码的编写往后顺延。

8. 设计原则
模拟是避免做傻事的最佳方式。在你自己苦思冥想去解决一个问题之前，先看看是不是有其他人已经有了非常漂亮的解决方式。比如我们需要学习一些设计原则来避免自己少走弯路，尽快写出伟大的程序。

开闭原则（OCP） ，这个原则应该大家多知道，并且都用过，但不一定用的很好。对修改关闭，对扩展开发。
不自我重复原则（DRY） ，关系到让系统中每一个信息与行为的片段都保存在单一，合理的地方。
单一自责原则（SRP） ，也叫内聚力。
Liskov替换原则（LSP） ，之类必须能够体会其基类。比如将长方形作为基类，那正方形就不应该成为长方形的之类，因为正方形不能替代长方形，长方形可以分别设置长宽，而正方形在设置长的时候宽必然跟着改变。
在我们需要使用继承之前先考虑委托、组合与聚合。
聚合和组合的区别在与，聚合让你使用来自其他类的行为，但没有限制这些行为的生命和周期，即使在聚合对象被摧毁之后，被聚合的行为仍继续存在。

9. 迭代与测试

大多数时候，客户不在乎你所创建的OO原则或者图形，他们只想要软件做它该做的事。所以很多时候伟大软件的编写应该是迭代进行的。先针对整体轮廓操作，接着迭代应用程序的每个片段，直到完成。

迭代的过程中可以使用不同的开发方式。比如用例驱动开发和功能驱动开发，他们的区别是一个把焦点房在应用程序用例中的一个场景上，一个把焦点放在为完整的功能编码上。
测试阶段是必经阶段，它让你的软件缺陷大大降低，让你向我们的客户证明软件能运作。
另一种开发方式：测试驱动开发，以先编写测试用例再进行开发通过这些测试的方式来确保我们的软件是完整有效的。
编程实践的时候涉及到两种编程模式，契约式编程和防御式编程。契约式编程为你与软件用户同意遵守的软件行为建立一个共同的协议。防御式编程不信任其他软件，进行广泛的错误及数据检查以保证其他软件不会给你不良的或者不安全的信息。两种编程模式在不同情况下使用。如项目内部应该使用契约式编程，对外开发应该使用防御式编程。