1.《深入浅出面向对象分析与设计》
# 简介
将告诉你如何分析、设计以及撰写真正面向对象的软件：容易重用、好维护、可扩展的软件；不再使你心碎的软件；让你增添新功能而不会破坏旧机制的软件。你是否早已对市面上那些只有在成为专家以后读起来才有感觉的 OOA&D 书籍感到厌倦？你可能早就听说过 OOA&D 书籍能帮助你写出伟大的软件——让老板高兴、客户满意的软件。但如何办到呢？
- 豆瓣链接：点击进入 (opens new window)
- 下载链接：可关注 OldBirds 公众号联系获取
# 伟大的软件的意义是什么？
第一，伟大的软件必须让客户满意，做客户要它做的事。
第二，伟大的软件是设计良好、编码良好的并且易于维护、重用及扩展。
当你要添加自己的东西到程序中，或将它重新利用在其他应用程序中时又如何呢？只让软件完成客户交代的事情是不够的，你的软件是最好经得起时间的考验。
# 伟大软件的简易三步骤
- 确认你的软件要客户要它做的事。
- 运用基本的 OO 原则来增加软件的灵活性
- 努力实现可维护、可重用的设计。
# 每个对象忠于自己的工作
1.对象应该做其名称所指之事
假如对象名为 “Jet”，它可能应该是 takeOff() 与 land()（起飞与降落），而不该是 takTicket()--那是其他对象的工作，不属于 Jet
2.每个对象应该代表单一概念
不要让对象担负双重或三重责任。避免使用一个 Duck 对象同时表示会呱呱叫的真正鸭子、黄色的塑料鸭或者低头躲避以免被棒球打到的人。
3.未使用的特性是无用的赠品
假如你有一个对象经常有空值或者 null 的特性，你可能有一个对象在做一种以上的工作。假如你的某个特性很少有值，为何该特性是此对象的一部分？要不要有一个较好的对象仅使用原有特性的子集(subset)?
# 封装
- 让你将应用程序分成一组一组合乎逻辑的部件
- 任何时候看到重复程序代码，就找个地方进行封装
- 封装背后的想法是要保护应用程序某一个部分信息免遭其他部分的干扰。
- 通过分解出应用程序的不同部分，你能改变一部分而无需改变整个应用程序。一般而言，你应该封装应用程序中变化可能很大的部分，让它们远离保持不变的部分。
# 用例
用例是捕捉新系统或软件变更的潜在需求的技术。每个用例提供一个或多个场景，传达系统如何与终端用户或其他系统交互以及实现特定目标
# 一个好的用例的三个基本部分
1.清楚的价值
每个用例对于系统都必须有明确的价值。假如用例无助于客户实现目标，这个用例便没有什么价值。
2.起点与终点 每个用例都必须有明确的起点与终点。某件事开始此流程，然后要有条件指明此流程已完成。
3.外部启动者 每个用例由外部启动者开启。有时启动者是人，有时可能是系统外部的任何事物。
# 需求
好的需求确保你的系统如客户所期待的那样运转。
确认需求涵盖了系统的所有用例。
运用用例找出客户忘了告诉你的事。
用例将揭露任何不完整、遗漏的需求，你可能要将它们加到你的系统中。
需求总是随着时间改变。
有了良好、完整的用例，文本分析是整理出系统所需类的简单且快速的方式。
# OO 原则
- 将变化之物封装起来
- 对接口编程，而不是对实现
- 应用程序中的每一个类只有一个改变的理由
- 类是关于行为与功能的
# 内聚力
内聚力度量单一模块、类或对象内各元素之间的连接度。软件的内聚力越高，应用程序中的每个类的责任就定义越好且越相关。每个类就具有特定一组紧密相关的动作要执行。
应用程序中内聚力越高，每个对象的工作就定义得越好。对象（及其工作）被定义得越好，就越容易将该对象从一个情境中抽出，然后在另一个情境中做同样的事。
# 跨对象变化封装
当你有一组特性跨对象变化时，使用集合，像 Map, 来动态存储那些特性。
# 分析与设计
- 设计良好的软件是容易改变与扩展
- 使用想封装与继承这种的基本 OO 原则来确保你的软件有灵活性
- 如果设计没有灵活性，就改变它！别与坏设计妥协，即使那是你自己的坏设计，要改就是要改。
- 确认你的每一个类都具有内矩形：每一个类都应该聚焦在把每一件事情做得好
- 随着软件的设计生命周期的展开，要持续努力提高内聚力
# 解决大问题
- 聆听客户，找出他们要你构建什么
- 用客户理解的语言组合功能列表
- 确认你的功能是客户真正想要的东西
- 运用用例图（以及用例）创建系统的蓝图
- 将设计模式运用到系统中较小的部分
- 运用基本的 OOA&D 原则为每一个较小部分设计程序
# 架构三问
1、它是系统本质的一部分吗？
该功能真的是系统实质意义的和兴吗？可以这样想想看：你能想象系统没有这个功能吗？假如不能，那这个功能可能是系统本质的一部分
2、这到底是什么意思
假如你不确定某项功能的叙述究竟是什么意思，把注意力放在该功能上可能就很重要。每当你不确定某件事情是什么，它就可能会花费你很多时间或者对系统的其他部分造成很多问题。要在项目早期把时间用在这样的功能上，而不是晚期。
3、我"到底"该如何做？
另一个要在早期就把注意力集中到的地方，是似乎真的很难实现的地方，或者对你来说全新的编程任务。假如你不知道如何处理某特定问题，最好花点时间去正视该项功能，这样它就不会在一路上产生诸多麻烦。
# 系统本质？
是指最基本的层次上系统是什么。话句话说，加入你去除所有的修饰、市场部丢进来的杂音以及所有很酷炫的想法，此系统会是什么？那就是系统的本质。
# 开闭原则（OCP, Open-Closed Principle）
对扩展开放，对修改关闭。
# 不自我重复原则 (DRY, Don't Repeat Yourself Principle)
通过将共同之物抽取出来并置于单一地方来避免重复的程序代码。
DRY 关系到让系统中的每一个信息与行为的片段都保存在单一、合理的地方。
# 单一职责原则（SRP, Single Responsibility Principle）
系统里的每一个对象应该具有单一职责，所有对象的服务都应该聚焦在实现该职责上。
当你的每一个对象都只有一个改变的理由时，你已经正确地实现单一职责原则。
一个类只做一件事且把事情做好，并且没有其他类共同分担该行为。
类所做的那件事可以是相当大的一件事。
# Liskov 替换原则（LSP, Liskov Substitution Principle）
子类必须能够替换其基类。
# 委托
一个类将做某事的任务委派给另一个类。它是继承的几个替代做法之一。
假如你需要使用另一个类的功能性，但不想改变该功能性，考虑以委托代替继承。
# 组合
将来自其他多个类的行为聚合起来
在组合中，由其他行为所组成的对象拥有那些行为。当对象被摧毁时，其所有行为也被摧毁。组合中的行为不存在与组合本身意外。
# 聚合
当一个类被用作另一个类的一部分时，但仍然可以存在于该类之外。
聚合让你使用来自其他类的行为，但没有限制这些行为的生命周期。