OOD in Interview

OOD
Catalogue
  1. 1. OOD in Interview
    1. 1.1. OOD要避免的情况
    2. 1.2. “SOLOD”原则
  2. 2. Design an elevator system
    1. 2.1. What? - 什么?
    2. 2.2. How? - 怎样?
    3. 2.3. Who? - 谁?
    4. 2.4. When? - 什么时间?
  3. 3. Think Process
    1. 3.1. Core Object
    2. 3.2. Access modifier
    3. 3.3. Use Cases
    4. 3.4. Class diagram 类图
    5. 3.5. Challenge

总结自:九章算法 - OOD1

OOD in Interview

Everything is an object, Usable!!!

  • 面试频率
    • Phone interview 低
    • Onsite interview 中高频
  • 高频公司
    • Amazon, Bloomberg, TripAdvisor, EMC, Uber…
  • 主要考察CS设计的基本素养，属于开放型设计类题目，能用上OOD的常见的一些设计思想！

OOA(Analysis) -> OOD(Design) -> OOP(Programming)

  • OOD问法
    • Can you design a … system? little amount of coding
    • Can you … for … system? need implementation

OOD要避免的情况

  • 1 不问清需求就开始设计，一定要和面试官!沟通”甲方”的需求！
    • Communication
  • 2 没有理解面试官想要问System Design，还是OOD，还是算法！
    • Think loud
  • 3 思路混乱，反复更改之前的设计！Usable！！！就好
    • Correctness & Reasonable
  • use case

“SOLOD”原则

  • S - Single responsibility principle
    • 一个类应该有且只有一个去改变它的理由，这意味着一个类应该只有一项工作。
  • O – Open close principle
    • 对象或实体应该对扩展开放，对修改封闭 (Open to extension, close to modification)
  • L - Liskov substitution principle 里氏替换原则
    • 任何一个子类或派生类应该可以替换它们的基类或父类
  • I - Interface segregation principle 接口分离原则
    • 不应该强迫一个类实现它用不上的接口 Implement
  • D - Dependency inversion principle 依赖反转原则
    • 抽象不应该依赖于具体实现，具体实现应该依赖于抽象
    • 只能class 依赖于Abstract, Imterface

Design an elevator system

Clarify : 通过和面试官交流，去除题目中的歧义，确定答题范围

What? - 什么?

  • 针对题目中的关键字来􏰁问，帮助自己更好的确定答题范围
  • 大多数的关键字为名词，通过名词的属性来考虑
  • Elevator, Building

How? - 怎样?

  • 针对问题主题的规则来􏰁问，帮助自己明确解题方向。
  • 此类问题没有标准答案，你可以􏰁出一些解决方法，通过面试官的反应， 选择一个你比较有信心(简单)的方案
  • Rule
    • 同向 > 静止 > 反向，当运行时不能按下反向的楼层
    • 电梯至少需要三种状态，并且要知道当前在哪一层

Who? - 谁?

  • 设计由人主导 VS. 设计由系统主导?
  • (Optional)通过思考题目当中是否有人的出现，来帮助确定解题范围
  • 一般可以考虑人的角色以及人的属性，看是否题目需要

When? - 什么时间?

  • (Optional)通过思考题目当中和时间相关的属性，来帮助确定解题范围
  • 和时间相关的问题一般都比较细节，可能会有意想不到的帮助

Think Process

Core Object

为了完成设计，需要哪些class？

  • 以一个Object为基础，往往就是需要设计的system！
  • 确定objects之间的映射关系(4~5个Object)

Access modifier

  • package
    • 如果什么都不声明，变量和函数都是package level visible的，在同一个package内的其他类都可以访问
  • public
    • 如果声明为public，变量和函数都是public level visible的，任何其他的类都可以访问
    • 用”+”表示一个变量或者函数为public
  • private
    • 如果声明为private，变量和函数都是class level visible的，这是所有access modifier中限制最多的一个。
    • 仅有定义这些变量和函数的类自己可以访问。
    • 在类图中，用”-”表示一个变量或者函数为private
  • protected
    • 如果声明为protected，变量和函数在能被定义他们的类访问的基础上，还能够被该类的子类所访问。
    • protected也是OOD当中实现继承的重要手段
    • 在类图中，用”#”表示一个变量或者函数为protected

Use Cases

e.g. Elevator

  • Take external request
  • Take internal request
  • Open gate
  • Close gate
  • Check weight

Class diagram 类图

  • 为什么要画类图?
    • 可交付，MinimalViableProduct
    • 节省时间，不容易在Coding上挣扎
    • 建立在Usecase上，和之前的步骤层层递进，条例清晰，便于交流和修改
    • 如果时间允许/面试官要求，便于转化成Code
  • 怎么画类图?
    • 遍历你所列出的usecases
    • 对于每一个usecase，更加详细的􏰀述这个usecase在做什么事情 (例如:take external request -> ElevatorSystem takes an external request, and decide to push this request to an appropriate elevator)
    • 针对这个􏰀述，在已有的Coreobjects里填充进所需要的信息

Challenge

  • What if I want to apply different ways to handle external requests during different time of a day?
    • Solution 1: if - else
    • Solution 2: Strategy design pattern
Share