简读《Head First面向对象分析与设计》

忙里偷闲系列，本阶段最后研发相关的一本书。接下来需要换换脑子。本文都是转载，自己做记录，并没什么可读性。

OOA&D只是一种编写软件的方法，它聚焦在确保你的软件做它该做的事并且是设计良好的。这表示你的软件有灵活性，容易改变，好维护并且可重用。
当程序正常运行，客户是满意的；当程序持续正常运行，客户是满意的；当程序能够升级，客户是满意的；当程序能够被重复利用，程序设计师是满意的；当程序就要有灵活性，程序设计师是满意的。

低耦合，
三个步骤：确认客户的正确需求-》用基本的OO原则增加灵活性-》努力实现可维护、可重用的设计。
确认你的软件在做客户要它想做的事-》测试驱动 test drive-》测试通过后-》客户满意后-》回到上面的三个步骤-》
委托：一个对象将操作转交给另一个对象的动作，第二个对象代表第一个对象执行该操作。

OOA&D提供一种产生设计良好的应用程序的方法，同是满足客户和程序设计师。
找出应用程序中经常改变的部分，试着将它们与其他不改变的部分分开。
一旦完成基本功能，就重新细化你的设计，让它更灵活。

---

收集需求
需求：需求是单一的需要，详细说明特定产品或服务应该做的事。最常用在系统工程或软件工程的正式用语中。
确认你的软件做客户要它做的事。
编写介绍用例3要素：价值明确，如果用例对于用户目标没用，那就没必要写；必须明确的起点或者终点；每个用例都必须由外部启动者开启。
注意随着代码更新编写测试用例。
主要路径和替换路径
用例的真正威力在于可以协助建立完整的需求列表，判断需求列表是否含盖了每一件事。

---

需求变更
原则：客户永远是对的。需求总是在变的。
测试驱动
需求的变动揭露出关于系统你还不知道的问题；变更是经常的，随着你的每次实现，系统总是随之改变。

---

在真实的世界中，软件遇见的实际情况远远要比用例多。确保事情正常运作以及真实世界不会摧毁你的应用程序的关键是分析：在程序发布前，想出潜在问题，然后解决。
查看用例里的名词以整理出类与方法的动作叫做文本分析。用例里的动词通常是系统中对象的方法。
编写用例–需求整理–文本分析–UML画类图

---

高内聚才能引发低耦合
内聚力，cohesion。内聚力量度单一模块、类或对象内各元素之间的连接度（degree of connectivity）。软件的内聚力越高，应用程序中每个类的责任就定义得越好且越相关（well-delined and related）。每个类就具有特定一组紧密相关得动作要执行。

---

软件架构师architect，是软件项目得灵魂人物，必须兼顾功能需求、开发部署、运作性能、技术风险以及系统灵活性与可维护性等，在有限资源与时间下，设计出最合适的软件架构。
对接口编码，而不是对实现编码

---

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

架构三问：它是系统本质的一部分吗？这他妈的是什么意思？我到底该如何做？

---

1开闭原则2不自我重复原则3单一职责原则4替换原则5

---

OO编程工具组：需求；分析与设计；解决大问题；OO原则；
6/7：运用用例图与关键功能列表，将简单的远景陈述转换成应用程序的架构；
8：OO原则帮助我们编写软件良好，有灵活性的OO软件；
1：编写伟大软件的3个步骤：确认你的软件做客户要它做的事-》运用基本的OO原则来增加软件的灵活性-》努力实现可维护、可重用的设计；
但，，，你的客户在意的不是这些，她们只想软件能做他该做的事。
伟大软件的编写是迭代进行的。先针对整体轮廓操作，接着迭代应用程序的每个片段，直到完成。
迭代的两种基本方式：功能驱动开发；用例驱动开发；