第三周设计模式总结

初始入行我头疼于功能的实现，努力对领导交差保证工作平稳。



之后尝试负责一些业务、项目之后发现，功能实现仅仅是最基本的要求。于开发：性能，响应速度，资源消耗；于团队：联调测试，沟通效率；于产品：上线之后能否满足初始的期望，如拉新、业绩，还有之后的可扩展迭代等等。



程序员负责产品功能的实现，但一个合格的产品绝不是为了实现功能，每个产品都应该有它的使命初衷，有各自的迭代发展方向。



至于设计模式所负责的任务应该属于可迭代性上，不管是观察者模式的可插拔组件，代理模式的灵活性，装饰模式的增强性，其实大体都围绕着高可用，低耦合。代码的可阅读性，灵活性，体现着码农的智慧与优雅，同时也保证着产品本身的生命力。



后来发现工作不只是为了工作，也需要对自己交代得下去。

本周笔记

• 模版方法

• 模版方法通过继承抽象类的方式来实现扩展

• 父类负责算法的轮廓和骨架

• 子类负责算法的具体实现

• 形式：

• 抽象方法：强制子类实现该步骤

• 具体方法：子类可以选择是否覆盖，如果明确不让子类覆盖，需要表明final

• 钩子方法：子类可以选择性覆盖，在特定时机执行

• 策略模式

• 有三种角色：应用程序，策略接口，策略实现

• 策略模式结合模版方法：策略模式决定模版方法调用顺序，初始化 -> 执行具体方法 -> 收尾，开发人员继承实现模版方法，定制化自己的具体逻辑

• 组合模式

• 类似树形结构，执行根节点方法，即可执行根节点本身以及所有子节点方法

• 如Junit Test类

• Hive通过HQL实现MapReduce过程：

• HQL -> 通过解析器，被解析成抽象语法树

• 进行语义分析优化

• 生成执行计划（通过MR实现），交给执行器（Hadoop）处理

• 代理模式和装饰模式的区别

• 代理模式在使用的时候并不知道实现类或其逻辑，在运行期间才能确定，常用手段如cglib代理，jdk动态代理，通过接口或者父类，灵活注入特定功能子类

• 装饰模式分为装饰者和被装饰者，装饰者通过被装饰者的构造参数注入，被装饰者执行自己方法前先调用装饰者的方法，可以灵活扩展增强方法