1. Algorithm 一道算法题

本周的算法题是串联所有单词的子串

本题比较有代表性的一点是利用滑动窗口+双hashmap解决问题，有很多问题可以归纳为为该种问题解决

2. Review 读一篇英文文章

本周继续学习 MF 的# Inversion of Control Containers and the Dependency Injection pattern

Inversion of Control

When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.

当这些容器谈论它们之所以有用是因为它们实现了“控制反转”时，我感到非常困惑。控制反转是框架的常见特征，所以说这些轻量级容器之所以特别是因为它们使用了控制反转，就好像说我的车子之所以特别是因为它有轮子一样。

The question is: "what aspect of control are they inverting?" When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like "Enter name", "enter address"; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.

问题是：“他们正在反转控制的哪个方面？”当我第一次接触到控制反转时，它是在用户界面的主控制方面。早期的用户界面由应用程序控制。你会依次收到命令，例如“输入姓名”，“输入地址”；你的程序会驱动提示并获取每个提示的响应。在图形界面（甚至是基于屏幕的界面）中，界面框架会包含这个主循环，而你的程序则为屏幕上的各个字段提供事件处理程序。程序的主要控制权被反转，从你移交给了框架。

For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

这些新型容器的控制反转是关于它们如何查找插件实现的。在我简单的示例中，lister 通过直接实例化来查找查找器的实现。这样的做法会阻止查找器成为一个插件。这些容器使用的方法是确保任何使用插件的用户都遵循某些约定，允许一个独立的组装模块将实现注入到列表器中。

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

因此，我认为我们需要为这个模式取一个更具体的名称。"控制反转"这个术语太过泛泛，因此人们会感到困惑。在与各种IoC倡导者的讨论中，我们最终确定了名字为“依赖注入”。

I'm going to start by talking about the various forms of dependency injection, but I'll point out now that that's not the only way of removing the dependency from the application class to the plugin implementation. The other pattern you can use to do this is Service Locator, and I'll discuss that after I'm done with explaining Dependency Injection.

我将首先讨论各种形式的依赖注入，但我现在要指出的是，这并不是将应用程序类与插件实现解耦的唯一方法。你可以使用另一种模式来实现这一点，即服务定位器模式，我会在讲解完依赖注入后再进行讨论。

3. Techniques/Tips 分享一个小技巧

使用 switch 进行类型判断之类的代码，大多可以考虑使用多态来重构它

4. Share 分享一个观点

最近在学习 Martin 的代码整洁之道，有很多新的感悟，其中一点是将函数尽可能写得短小，使之符合 SOLID 原则（单一职责，开放封闭，liskov 替换，接口隔离，依赖倒置），一个函数应该只做一件事，如果你的函数名不好取或者是函数名包含 and、or 等词时，往往暗示函数的职责不清楚，做了多件事，此时应该分析拆分函数，使之符合单一职责原则，一般函数超过10行就算比较多了，要考虑进行重构函数了