Head FIrst OOAD 读书笔记

Head FIrst OOAD & 期中project的反思

论如何优雅地在实验报告吹水…

(大雾:明明实验报告基本都写完了…)

project反思等稍微空闲一些再补充

• 伟大软件的三大步骤

  1. 确认软件做客户要它做的事
  2. 运用基本的OO原则增加软件的灵活性
  3. 努力实现可维护,可重用设计

• 任何时候看到重复的程序代码,就找个地方进行封装

  1. 委托
     
     • 保护你的对象免受其他对象的改变而干扰
  2. 低耦合
• 为错误作规划
  
  • 替换路径
  • 用例use case
  • clear value
  • starting point & stopping point & condition
  • external initiator
• 需求改变
  
  • 设计决策 ≠ 运作形式(取决于顾客)
• 场景
  
  • 从第一部到最后一步通过的用例
  • 用例可以适用于不同场景,但有相同的客户目标

• 确保软件运行在真实世界里

  • 文本分析:
  • 用例 名词 => 类,动词 => 方法,

• 抽象类是实际实现类的占位符(placeholder)

  • 每当在两个以上地方找到共同行为时候,小心的抽象到一个类里面重用
• 编码一次,查看两次
  
  • 愿意改变自己的设计以及从其他程序那里继承而来的设计

软件架构

有时候编写伟大程序代码的最佳方式

是在允许的情况下将程序代码的编写往后顺延

• 化整为零成单独的功能片段

• 封装变化之物

• 对接口编码

• 了解系统应该去做什么

• 分析真实情景,注意交互

  • 做客户的翻译

• 架构的要点是减少风险和建立次序

  ​

设计原则

OO原则

• 接口
  
  • 对接口编码而不是对于实现(基类)
• 封装
  
  • 保护类免于不必要的改变
  • 把变化之物封装起来
• 变更(内聚性)
  
  • 确保每个类只有一个改变的理由
  • 让每个类只做一件事

开闭原则OCP

• 禁止为修改 而关闭
  
  • 比如private方法
• 允许为扩展 而开放
  
  • 子类可以改变行为

不自我重复原则DRY

将共同之物抽取出来并置于单一地方避免重复的程序代码

• 让系统中每一个信息和行为都保存在单一/合理的地方
  
  • 对于AI minmax的封装依旧有重复的代码

单一职责原则SRP

• 每一个对象只有一个改变的理由
• 内聚力
• the ___ ___ itself读起来是否顺畅
  
  • 这里反思: 期中pro中棋盘的设定
  • 不应该模拟”下棋”,下棋是人去下棋,
  • 但是player又不能随意修改棋盘,
  • 所以player应该得到棋盘的一个code来下棋
  • 棋盘不应该提供下棋的接口.只应该作棋盘
  • 所以game类应该保护棋盘,提供下棋的接口

Liskov替换原则LSP

• 子类型必能替换其基类型选择继承
• 想要使用另一个类的功能性,但是又不想改变改功能性,用委托(delegation)代替继承(把行为委托出去)
• 使用组合(composition)代替继承 : 重用一个或多个类的行为
• 聚合(aggregation): 当一个类用作另一个类的一部分是,仍然可以存在于该类之外(对象确实独立存在)

伟大软件

• 伟大软件是自顶向下迭代编写的
  
  • 面向功能型聚焦
  • 面向流程型聚焦
• 编写测试场景,扮演客户
• 契约式编程
  
  • 防御性编程(exception)
• 只暴露于用户交互的类给用户
  
  • 不与用户交互的类可以在对客户端影响程度最小的程度的情况下被改变

生命周期

1. 功能列表(应该做什么)
2. 用例图(如何被使用)
3. 分解问题
4. 迭代开发
   
   1. 需求
   2. 领域分析
   3. 初步设计
   4. 实现
5. 教辅

十大主题

• IS-A(继承) HAS-A(组合,聚合)
• 用例格式->聚焦于交互
• 反设计模式
• CRC卡实现单一职责原则
• 度量抽象化密度
• UML顺序图
• UML状态图
• 单元测试
• 编码要求(代码风格)
• 重构: 改变程序代码的内部结构而不影响行为