| 作 者： | （美）麦克劳克林（Mclaughlin,B.D） 等著；OReilly Taiwan公司 编译 |
| 出版社： | 东南大学出版社 |
| 丛编项： | |
| 版权说明： | 本书为出版图书，暂不支持在线阅读，请支持正版图书 |
| 标 签： | 软件工程/开发项目管理 |
| ISBN | 出版时间 | 包装 | 开本 | 页数 | 字数 |
|---|---|---|---|---|---|
| 未知 | 暂无 | 暂无 | 未知 | 0 | 暂无 |
介绍
谁适合读这本书？
我们知道你在想什么
元认知
让你的脑袋顺从你的方法
读我
技术审阅团队
致谢
1 伟大软件由此开始：良好应用程序的基石
永远的摇滚乐！
Rick的金光闪闪的新应用程序
什么是你要改变的第一件事？
伟大软件……
伟大软件的简易三步骤
先聚焦在功能性上
测试驱动
寻找问题
分析
运用基础的OO原则
设计一次，设计两次
改变你的应用程序有多简单？
封装变化之物
委托
最后的伟大软件（就现在而言）
OOA&D关系到编写伟大软件
要点
2 给客户所需之物：收集需求
大显身手的机会来了
测试驱动
不正确的使用（有一点）
那么，需求究竟是什么？
创建需求列表
为错误作规划
替代路径（alternate path）处理系统的疑：
（再次）介绍用例
一个用例，三个部分
按照用例检查需求
你的系统必须在真实世界里运作
认识快乐路径（Happy Path）
OOA&D工具箱
3 山可移，此情永不渝……现在，情况有变：需求变更
你是英雄！
牺牲品？
软件分析与设计的不变真理
可选路径？替换路径？谁能分得清？
用例对你而言必须合理
从开始到完成：单一场景
替换路径的真心话
完成需求列表
重复程序代码，逊！
最后的测试驱动
写下你自己的设计原则
OOA＆D工具箱
4 将你的软件带进现实世界：分析
一只狗，两只狗，三只狗，四只狗……
你的软件有其情境
识别问题
规划解法方案
两位程序员的故事
委托绕道
低耦合应用程序的威力
注意用例里的名词
从好分析到好类……
类图解析
类图不是一切
要点
5 第一部分：诸行无常——良好的设计
Rick的吉他事业蒸蒸日上
抽象类
类图解析（再一次）
UML小抄
设计问题的警告
通往伟大软件的三步骤（重访）
插曲：OO大灾难
5 第二部分：给你的软件30分钟的伸展操——灵活的软件
回到Rick的搜索工具
仔细瞧瞧search（）方法
分析的好处
类实际上关系到行为
设计之死（决策）
将坏的设计决策转变成好的
Rick的软件中的“双封装”
不要害怕犯错及改变
瞧！Rick的具有灵活性的应用程序
测试驱动Rick的设计良好的软件
改变Rick的软件有多容易？
变更容易性的大挑战
具有内聚性的类善于处理好单一事情
设计／内聚力生命周期
伟大的软件通常就是“够好的软件”
OOA＆D工具箱
6 “我的名字是Art Vandelay”：解决真正的大问题
解决大问题
关键在于你如何看待大问题
需求与用例是个好起点……
共同性与变化性
整理功能
功能与需求之间的“差别”
用例不总是帮你看出整体轮廓
用例图
小小参与者
参与者也是人（好吧，不全然）
做一点领域分析吧
化整为零，个个击破
别忘了真正的客户是谁
何谓设计模式？
OO&D的威力（以及一些小常识）
OOA&D工具箱
7 为混乱带来次序：架构
感觉有点头昏吗？
我们需要架构
从功能开始
什么是架构的意义？
架构三问
减少风险
场景有助于减少风险
一次把焦点放在一个功能上
架构是你的设计结构
再访共同性
共同性分析：通往灵活软件之路
什么意思？问客户吧。
减少风险有助于伟大软件自
要点
8 原创性被高估：设计原则
设计原则大集合
开关原则（OCP）
OCP，一步一步来
不自我重复原则（DRY）
DRY完全关系到一个地方一个需求
单一职责原则（SRP）
找出多重职责
从多重职责到单一职责
Liskov替换原则（LSP）
子类化的误用：误用继承的案例研究
LSP揭露继承结构所隐藏的问题
子类型必须能替换其基类型
违反LSP造成令人困惑的程序代码
将功能性委托给其他类
使用组合将来自其他多个类的行为集合起来
聚合：组合，但没有突然的结束
组合VS．聚合
继承只是选项之一
要点
OOA&D工具箱
9 软件终究为客户服务：重复与测试
你的工具箱满了
伟大软件的编写是迭代进行的
更深入地迭代：两种基本选择
功能驱动开发
用例驱动开发
两种开发方式
功能分析
编写测试场景
测试驱动开发
再探共同性
强调共同性
强调封装
比对你的测试与设计
测试案例解析……
向客户证明
到目前为止，我们一直在按契约编程
按契约编程关乎信任
防御性编程
将你的应用程序分解成较小的功能块
要点
OOA&D工具箱
10 组合在一起：OOA&D生命周期
开发软件，OOA&D风格
对象村旅游
对象村地铁线路图
功能列表
用例反映使用性，功能反映功能性
现在开始迭代
仔细看看地铁的表示
使用或不使用Line类……那是个问题
对象村地铁的关注要点（Subway类）
保护你的类（还有客户的类）
中场休息
回归需求阶段……
聚焦于程序代码，然后聚焦于客户
迭代（iteration）让问题比较容易
路线看起来像什么？
让自己看看对象村！
第三次迭代，有人要试试吗？
旅程未结束……
附录1：本书遗珠
附录2：欢迎光临对象村
