1.什么是 OOA、OOD、OOP
- 1.OOA : Object-Oriented Analysis(面向对象分析方法)
强调用 「抽象」 站在整体的角度进行分析问题而「不过多考虑具体实现」，也就是注重整体。
- 2.OOD : Object-Oriented Design (面向对象设计)
是对 OOA 的过渡环节及规范整理，处理各种的依赖关系，强调应该「依赖抽象」而不是具体实现。
- 3.OOP : Object Oriented Programmin(面向对象编程)
利用封装、继承、多态使得程序达到「重用性、灵活性、扩展性」
2.怎么利用 OOA、OOD、OOP
- OOA Analysis 分析什么？
面向对象分析、分析的是对象，对象从哪里来？从需求中来
- OOA Analysis 分析什么？
- OOD Design 怎么设计？
面向对象设计、需要将这些对象关联起来，封装成一个独立类、模块、系统
- OOD Design 怎么设计？
- OOP Programming 抽象编程
面向对象编程、封装、继承、多态，易维护、易扩展
- OOP Programming 抽象编程
简单画个图再来温习下：
OOA、OOD、OOP
- 做好需求分析，系统设计，抛弃复制粘贴，主导开发流程.
- 合理设计⾼层抽象与低层实现，减少依赖耦合
- 剥离⾼内聚可复⽤代码，从而避免需求变动⽽导致整体重构、重写。
具体干什么
3.写代码前该做些什么
想清楚是什么 => 与产品讨论反复确认 => 拆分技术点 => 优先处理业务，其次在是UI => 具体实现
- 先想清楚产品到底要一个什么样的功能，这个功能对产品来说是否真的那么重要，有没有什么更能放大这个效应的做法。
- 与产品讨论，理解他们通过APP想表达的需求，将它们转化成真正的需求，并画出流程图与产品反复确认。
- 需求理解好了，可以先拆分调研相关技术点。先不要急着去表达这个功能实现不了，这个效果要花时间。不妨客观的分析下（反正都要实现，为什么不把它做的好点呢）
- 有个大抵的了解之后，团队在一起讨论下，采用什么具体实现，谁来实现。 (务必让每个人都对代码有整体上的认识，不要各自维护自己的小模块，不利于成长，也不利于团队)
- UI一般都要比业务逻辑改动的频繁，所以最好不要急着画UI，只要有个大致的UI框架就可以了。先把业务逻辑完善（网络交互， cache，点击事件，跳转）如果有盈余，可以写unit test来测试C层或者P层逻辑的正确性。没问题了再写UI实现。
- 剩下的具体实现呢，如果没有现成的代码可以用，可以再拆分成几个task。先自己将tasks通过workflow串在一起，不管是流程图，还是TODO伪代码都行。再针对每个task来搜对应的解决方案。
- 所有技术问题不可能是无解，只要耐心，肯定能找到解决方案。别怕麻烦，别图省事，碰到的每个问题都是你进步的阶梯。如果真不能解决，那就换个折中的解决方案嘛，沟通灰常重要的！
4.什么会增加额外的工作量和风险？
1.复制粘贴（不经过思考）
复制的代码往往一些实现不理解，代码中可能隐藏着配置未能注意到，导致出了 bug 需要找很久2.代码规范不好（可维护性差）
命名规范，未写注释，写过后不知道这段代码做什么的，难以维护。3.重实现，轻设计（不考虑复用和解耦）
所有的代码都写在一个类中，忽视设计原则，不能合理的提取，导致一个类比较臃肿，后期难以理解和维护。
