今天完成的事情

听老大讲简洁代码之道

8.忘掉继承

继承的优点是：

新的实现很容易，因为大部分是继承而来的
很容易修改和扩展已有的实现

缺点：

打破了封装，因为基类向子类暴露了实现细节

白盒重用，因为基类的内部细节通常对子类是可见的
当父类的实现改变时可能要相应的对子类做出改变
不能在运行时改变由父类继承来的实现

还有当系统的结构比较复杂时，继承的层次会很多，导致代码的复杂度陡增，十分不便于维护和重构

在实际开发中，应该尽量不用继承，用组合来代替继承

组合可以理解为当希望类具有其他类的属性和方法时，不在通过继承，而是将其他的类作为属性注入到此类中，这样的方法可以使类同时具有多个其他类的功能，而且当系统比较大时，也不必构建一个庞大的层次很深的继承结构，而是实现类于类之间的平面化关系，构建一个新类，之多只需要引用其他的类一次，类于类之间的层次至多为两层

10.合适的场景使用合适的语言和工具

针对特定的问题，使用最合适的解决工具，方法，而不是只使用自己擅长的工具

不过这里牵涉到一个问题，采用已经熟悉的方式，比较稳，而采用并不熟悉的技术，首先需要额外的学习成本，其次是会面临额外的不熟悉因素产生的风险

第一个问题本质上是程序员是否善于接受新技术，毫无疑问，应该养成这种能力

第二个问题，是由第一点延伸出的思考，一个程序员具有了快速掌握新的技术的能力，如果此技术是经过了大量实践检验的还好。不过，有一种情况是，程序员会使用快速掌握的新的技术去解决问题，但是，这种新的技术还不太成熟，则会面临比较大的风险。所以，对于这一段的理解，我想应是具有快速掌握解决特定问题的工具的能力，并且要选择比较成熟的技术

11.消息队列拯救世界

牵涉到了框架，架构的概念，感觉不好理解。

举的例子是，对于登陆功能，需要实现很多的附属功能，采用逐次调用的话，受制于数据库的性能问题，会有很长的耗时，采用多线程的方式，同样会受制于数据库，即使采用性能更好的数据库，也还是不能比较彻底地解决问题，采用消息队列的方式，大概是将那些附属功能常驻于程序中，登陆功能就只发送一条信息到中间件中，或者叫公告板，那些常驻的服务监听着公告板，一有信息就执行对应的操作，

理解还不到位

12.永远重构

可以利用ide进行类名的修改

对于比较长的代码块，抽象为函数

对于有重复的代码块，进行抽象并封装

先写单元测试，再写实现

先写方法签名，构建出整个体系结构，再写具体实现

明天的计划

再看看spring mvc

看复盘资料

遇到的问题

无

收获

如上