book
阅读小结
读完这本书，脑袋晕晕的。
这本书中，讲需求分析的方法的时候，那个用例的方法，收获比较大。通过518方法来分析需求，写用例。然后提取功能，做设计，这个学到了，以后可以用到自己的项目中去。
面向对象技巧这块比较难，设计原则和设计模式虽然多次听到，还不会用到实际的项目中去。
这本书带给我更多的是一种思考方法，当我拿到项目后，如何分析，如何设计，以及怎样把项目较好的实现。
参考
《面向对象葵花宝典——思想、技巧与实践》阅读记录
Chapter 1
第一次软件危机：复杂性
第二次软件危机：可扩展性、可维护性。软件生产力远远跟不上硬件和业务的发展
面向对象是一种新的软件方法
C++需要在运行时间、代码紧凑性和数据紧凑性方面能够与C语言相媲美
Java定位于互联网应用
面向过程：程序=算法+数据结构
面向对象：程序=对象+交互。“人的思想”。程序员可以按照人的思想来观察、分析、设计系统。
常见的可变的主要集中在客户需求部分，而不变的一般属于计算机系统的基础。
对于复杂的系统来说，性能的好坏是由设计来决定的，而不是由语言来决定的，更不会因为采用了面向对象而导致性能降低！
Chapter 2
类是面向对象领域里最基础的一个概念，也是面向对象分析和设计的基石。
类就是一组相似事物的统称。
设计属性的一个基本原则：属性最小原则，即“属性不可再分”
设计方法的一个基本原则：方法单一化原则，即“一个方法只做一件事”
软件类来源于现实类，但高于现实类。
程序员就是软件世界的上帝！
接口是一组相关的交互功能点定义的集合。
从设计的角度来看，抽象类是更高层次的抽象。
抽象：抽取比较像的部分出来。属性类似，行为类似
对象：对象就是一个具体的类，一个真实存在的类
抽象最主要的作用是“划分类别”，而划分类别的主要目的其实还是“隔离关注点，降低复杂度”。
抽象是面向对象领域里面发现类的主要方法。
封装、继承、多态是面向对象的三大核心特征。
封装数据的主要原因是“保护隐私”，封装方法的主要原因是“隔离复杂度”。
基本上程序都不会是你一个人写的。一种东西你是控制不了的，即“客户需求”。
多态屏蔽了子类对象的差异，使得调用者可以写出通用性的代码，而无须针对每个子类来写不同的代码。当增加新的子类时，调用者的代码无须变动就能适用新的子类
Chapter 3
需求模型->领域模型->设计模型->实现模型
Chapter 4
需求：对客户来说有价值的事情
功能：系统为了实现客户价值而提供的能力
需求分析的终极目的，就是要“挖掘客户的问题，实现客户价值”
记录员->分析员->引导员
需求分为功能属性和质量属性
采用用例方法分析需求的时候，采用纯文本来描述需求
用例图，不是用来描述用例的，而是用来描述系统的图形
需求分析518方法
5W : When Where Who What Why
1H : How
8C : Performance Cost Time Reliability Security Compliance Technology Compatibility
5W
Chapter 5
Chapter 6
类是要最终满足客户需求的
”软件类“是软件系统内部的一个概念，而领域类是业务领域的概念，并不是每个领域类最终都会体现在软件体系中
一般不需要将拆分的辅助类体现在类模型中，仅在编码的时候拆分即可
当我们发现一个对象的状态比较复杂的时候，就需要设计对象的状态模型。 状态图的最明显优势是可以一木了然地看到关键对象的所有状态和变更条件。
当我们发现一个处理流程比较复杂的时候，就需要设计流程的活动模型。
动态模型根本作用是便于我们去思考和理解实现过程
只需要针对一些关键的、核心的、复杂的业务或者功能进行动态模型设计即可
模型!=代码；模型不等于伪码，更不等于代码；模型的主要目的是指导代码的编写，但不是代码的文字化描述
Chapter 7
在实际应用中除非万不得已，否则一般不推荐使用友元机制
Chapter 8
无论是”低内聚“，还是”高耦合“，其本质都是"不稳定"
SRP只适合那些基础类，而不适合基于基础类构建复杂的聚合类
优先使用对象组合，而不是继承
偶然内聚 逻辑内聚 时间内聚 过程内聚 信息内聚 顺序内聚 功能内聚
无耦合 消息耦合 数据耦合 数据结构耦合 控制耦合 外部耦合 全局耦合 内容耦合
Chapter 9
Chapter 10
语言本身最直接的作用是"表达"和"交流"；信息传递
UML!=设计
UML最大的作用在于"统一"；使用UML的根本目的是为了表达
用例图最大的作用是将复杂的用户需求通过图形清晰地表达出来；用例图架起了一座从客户需求过渡到软件开发的桥梁；用例图的主要作用是直观地描述系统对外提供的功能；在用例图中，一个角色应该只承担一个职责
状态图：状态变化
活动图：实现流程
活动图更加适合描述高层或者总体设计，而序列图更加适合描述底层或者详细设计
Chapter 11
架构设计是为了隔离关注点，降低复杂度；架构设计是为了分工合作
架构=模块+交互
架构设计是"面向对象"思想的一个具体应用。"面向对象"的思想既可以指导程序设计，也可以指导架构设计
架构设计最初的来源就是“客户的业务系统”；最初的架构就是对客户业务系统的模拟
唯一不变的是变化；满足客户需求，然后超越客户需求
买单的例子
用例
【用例名称】
买单
【场景】
Who：顾客、收银员
Where：商店的收银台
When：营业时间
【用例描述】
1. 顾客携带选择好的商品到收银台；
（这一步没有异常）
2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息；
2.1 扫描仪坏了，必须支持手工输入条形码；
2.2 商品的条形码无法扫描，必须支持手工输入条形码；
2.3 条形码能够扫描，但查询不到信息，需要收银员和顾客沟通，放弃购买此产品
3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额；
（这一步没有异常）
4. 顾客将钱交给收银员；
4.1 顾客的钱不够，顾客和收银员沟通，删除某商品；
4.2 顾客的钱不够，顾客和收银员沟通，删除某类商品中的一个或几个（例如买了 5 包烟，去掉两包）
4.3 顾客觉得某个商品价格太高，要求删除某商品；
4-A：顾客使用信用卡支付
4-A.1 信用卡支付流程（请读者自行思考完善，可以写在这里，如果太多，也可以另外写一个子用例）
4-B：顾客使用购物卡支付
4-B.1 购物卡支付流程
4-C：顾客使用会员卡积分支付
4-C.1 会员卡积分支付流程
5. 收银员清点钱数，输入收到的款额，系统给出找零的数目；
（这一步没有异常）
6. 收银员将找零的钱还给顾客，并打印小票；
7. 买单完成，顾客携带商品和小票离开；
【用例价值】
顾客买完单以后，就可以携带商品离开，而超市也将得到收入；
【约束和限制】
1. POS 机必须符合国标 XXX；
2. 键盘使用中文，因为收银员都是中国人；
3. 一次买单数额不能超过 99999RMB；
4. POS 机要非常稳定，至少一天内不要出现故障；
功能
| 功能编号 | 功能描述 | 备注 |
|---|---|---|
| 001 | 扫描商品条形码 | NA |
| 002 | 手工输入条形码 | 在用例的几个步骤中有体现 |
| 003 | 删除某商品 | 在用例的几个步骤中有体现 |
| 004 | 删除某类商品中的一个或几个 | NA |
| 005 | 顾客使用信用卡支付 | 功能点比较大，如有需要，可以继续拆分。 |
| 006 | 顾客使用购物卡支付 | 功能点比较大，如有需要，可以继续拆分。 |
| 007 | 顾客使用会员卡积分支付 | 功能点比较大，如有需要，可以继续拆分。 |
| 008 | 计算找零的数目 | 用例中是“给出” ，对应系统功能是我们改为“计算” ，因为这更加符合计算机的描述术语。 |
| 009 | 打印小票 | NA |
SSD
SSD
领域模型
领域模型
类图
类图
序列模型
序列模型
网友评论