2019-12-18依赖倒置这个东西懂得人是真懂，不懂的人是一点不懂。当初为了搞懂依赖倒置原则花了相当长时间去阅读大量的文章和书籍，看了很多代码事例，后来又看了面对对象设计原则才算基本理解。
之前给公司开发培训，他们仍旧听的一脸懵逼，觉得这是个噱头。直到我跟他们说：老板就是找个写代码的人，别把自己看的那么重。你们每天写那么多bug，别怪老板说要换人。他们才理解！作者回复: 这个解释精彩😁
3 15
2019-12-18我觉得linux的vfs也是这种依赖倒置的，vfs定义一组通用的函数，如read,write,open,close，具体的文件系统实现这些接口，系统调用的时候去调用file结构中的f_op（对应具体的文件系统操作）。 4
2019-12-19疑问: 按照我的理解，上层定义接口，对应到项目(传统三层架构)，就是controller 层定义 service 层的接口，service层定义 dao层的接口，是这样吗？ DI的目的是减少功能变化时，对代码的修改，可是我发现一旦这么做的时候，不但不能减少，反而会增加，因为功能的变化一般都是最上层的变化，比如: 参数的增加，减少，参数中字段的增加，减少，修改，这样的每一个变化都会影响到每一层的接口，所以在每一次功能变化的时候，都需要将整个调用链路的代码修改。 如果每层之间都加了防腐层，那每次变化都陷入到繁琐的改字段，测试字段之中。所有的unit test也要跟着变。这样真就是完完全全的牵一发而动全身! 有时我甚至觉得，把一个功能缩在一个类中，反而会更简单! 希望老师务必解答我的疑问，这个问题困扰我很久了!作者回复: 首先，依赖倒置后Service定义接口，DAO实现接口，不会导致变化更频繁，至少不会比原来DAO定义接口更频繁，因为从纯粹代码角度看，这个接口所有权的变化，换汤不换药，跟以前一样的。当然建议你用DDD的一些设计思路去设计服务和仓储，才能真正体现依赖倒置的优势，设计更稳定。
其次，即使仅仅换汤不换药，也可以强迫设计者从Service的角度去设计接口，而不是从DAO角度设计接口，从而使接口的设计更加符合业务特点。 3
2019-12-23电力系统用了依赖倒置原则，电力系统规定了用电的业务逻辑和插座接口，家用电器只要符合插座接口即可使用。 2
2019-12-30懂了懂了，看了3遍，听了3遍，基本理解，但是也不能太刻板的认为一定得是高层定义接口吧，只要都依赖抽象感觉就行了，不需要太计较这个抽象层在哪吧作者回复: 👍 建议看完模块二再回头看一遍，要计较的😁
1
2019-12-18请教老师一个问题，文中讲到我们平时使用的mvc开发模式是不满足依赖倒置原则的，因为不是高层定义接口抽象，但是即便是低层定义接口，只要不修改接口只修改实现，也是感觉没问题的，有必要强调这里的所属者吗？这个指导思想一般只是指导框架实践吧，平时编写代码好像都不会考虑这个 1 1- 2020-02-09Lamp实现ButtonServer的那个UML图，是不是要改成虚线加空心三角形？
作者回复: 从UML的语法应该虚线，实践中继承和泛化我一般没做区分，就是我在UML一篇提到的UML方言，不影响交流即可。
2020-02-05怎么觉得依赖倒置和面向接口编程说的是同一个东西，是哪里理解有误吗？老师帮解答下作者回复: 依赖倒置强调：接口使用者定义接口，而不是接口实现者定义接口。
面向接口编程的概念比较泛，通常不强调接口是谁定义的。
2020-02-04打卡～
2020-01-21看了这几篇我感觉：接口这种类型非常重要；接口定义的好坏代表了我们是否对一类操作“抽象”的恰当。作者回复: 是的
- 2020-01-19高层模块通过依赖底层模块的接口或者通过底层模块定义注解通过反射为高层模块提供功能，减少了高层模块直接依赖底层模块实现的耦合，提高了模块之间扩展性和维护性
2020-01-18老师说MVC不满足依赖倒置原则，这个我去年写一年业务代码的时候真的感觉到了。发现都是先想怎么写好sql，然后从dao->service->controller。陷入MVC框架里出不来，感觉是披着OOP的皮在写面向过程的代码。后来看了DDD才知道这是一种贫血性模式导致的结果。现在写通用模块的时候，就特别注意这些设计原则，感觉抽象能力真的太重要了!
2020-01-08看了以后，最大的感觉是为了开闭原则而开闭原则，提出了一系列的设计模式，感觉在讲述的过程中缺少一些推理和比较，直接就给结论，觉得很生硬
2020-01-06打卡，受启发
2019-12-23灯的那个那个例子让我想到了《Java 编程思想》每次都看一两章就拉下了，然后捡起来又是这两章。😂
2019-12-23我们在开发Java Web 应用时肯定是要对数据进行检验的。其中JSR303-JavaBean Validation 是一个数据检验规范 ，我们在开发业务代码时，使用规范预定义好的注解即可，是不需调用其具体实现Hibernate Validator。
2019-12-22老师可以具体阐述或举例说明下“策略层”、“方法层”、“工具层”的含义吗，是不是还有其他的层次名称的说法?
2019-12-19其实看很多框架的一些类的UML图，基本都是顶层是一个抽象的父类，然好一大堆接口引用。现在知道是依赖倒置思想作指导，但我有一个问题，想我们即使去使用抽象父类，来复用代码，虽然不会产生实例，但是怎么设计这个父类呢？有什么指导思想？比如我设计一个鸟类，比如会飞这个方法，有的特例企鹅就是不会飞，还有筑巢也是这样，怎么设计最好呢，还是压根不用父类？作者回复: 具体开发实践中，主要是用各种设计模式，而不是直接用设计原则去开发。设计模式也是基于设计原则的。
2019-12-19网络协议里面的七层模型，不同的层之间就是基于抽象来建立的，上层不知道下层的存在，每层只需要专注当前层的逻辑
2019-12-19受益良多，晚上就要试试写一写代码，来增加对这一原则的理解。改一个代码就跟株代码九族一样，到处找，累死了