这段父类先调，子类后调的构造真巧妙 static class SuperClassWithInjectMethod { int superCalled = 0; @Inject void install() { superCalled++; } } static class SubClassWithInjectMethod extends SuperClassWithInjectMethod { int subCalled = 0; @Inject void installAnother() { subCalled = superCalled + 1; } }

收获 1. 掌握了从子类递归寻找到父类的方法 while (current != Object.class) { current = current.getSuperclass(); } 2. 利用 Collections.reverse() 方法可以轻松反转集合，不用之前的逻辑反过来实现一遍 - 遇事不要冲动，直接想到的不一定是最好的 - 多思考，尽量使用工具方法简化问题 3. 渐渐的比之前更理解代码了

新增的两个filter，判断method的方法名和参数类型是否完全相同的地方，未做到TDD。 遗漏了一种测试验证：方法名相同，参数列表不同。 由子类方法标记@Inject 会覆盖且不执行父类@Inject方法的测试驱动了代码：.filter(m -> injectMethods.stream().noneMatch(o -> o.getName().equals(m.getName()) && Arrays.equals(m.getParameterTypes(), o.getParameterTypes()))) 没有什么问题， but 这段代码的作用是判断是否是重写方法。这里应该立即补充上判断是否是重写方法的测试

2. 最有感触的几点有：1.需求能变成测试用例，再根据测试用例需要的效果调整代码，减少了关注点。2.关于 Method Constructor Field Stream 和常见 Api 的用法也挺重要的。

1、下一步行动，核心流程 先快速解决遗留下的sad path。 重构生产代码之前，先重构测试代码。 2、测试代码的重构思路， 当前测试代码中有部分的测试是在专门测ConstructionInjectionProvider的功能。 故可以将相关的测试提取到该测试类中。