- 博客(6)
- 资源 (8)
- 收藏
- 关注
RSS订阅原创 6. 里式替换
按照惯例，看书的定义 简单说一下里式替换 在一段代码中,其父类能够被所有的子类变量替换，并且替换后不受任何影响，那么说这个继承关系是非常健康的。（因为子类不允许覆盖/重写父类的方法） 这个还是比较好理解的，就是名字有点洋气，只要看好如上面图片上的四点，其实还是非常简单的。 至于啥时候不遵守里式替换： 一般都是架构设计的时候才会用到继承，基本都回去遵守里式替换。 ...
2021-08-04 19:40:50
113
原创 5. 最少知道原则（迪米特原则）
按照惯例，先先发一段书里面的定义 这里面的含义不是对象和对象之间保持的联系越少越好，而是不要和不应该交流的对象进行交互。 举个例子： A、B、C三个系统 ，AC当初因为不能直接交流，而引入了B系统作为AC之间交流的跳板。 这时AC之间有两个接口其实是可以直接交流的，但是也不应该A调用C，还是应该通过B进行消息传递。 这就是最少知道原则的意思，我A系统知道B系统就可以了，我可以认识C，但是那样就越界了。 最少知道原则在那些情况可以打破，是真不知道，从来不敢违背过，尤其是以领域驱动设计为核心的架构，对这个原则
2021-08-04 19:29:14
248
原创 4. 接口隔离
按照管理，出书上的引用 其实意思就是，写接口的时候不要接口里面涉及一千个方法，要根据业务与接口的实际意义，做适当的拆分（适当不代表少，有时候适当的接口也有很多方法） 不实现接口隔离的坏处： 接口不隔离，接口的含义会很模糊 代码冗余，后期不好修改 容易被同事打 什么时候不进行接口隔离： 要是接口本身方法就不多，就那么五六个方法，用的地方也不多，那就别做太细的隔离了，一个接口就隔离出那么多接口文件，很难想象一个系统会有几千个接口。 ...
2021-08-04 19:14:39
148
原创 3. 单一职责
按照管理，出一个文章节选 核心思想就是：一个类、甚至一个方法别做太多的功能，比如说订单接口不要去做支付相关接口，举例说明违背单一职责的缺点： 代码可能会很多，一个方法可能会有好几千行代码 阅读性不好，一个接口做很多事很难看清他的所有业务逻辑 扩展性不好 ，因为一个方法做了很多事情，一旦需求新增了一些功能点或者修改了功能点，五千来行代码的话对于应届生基本很难去改 但是有时候单一职责是可以打破的，原则就是用来打破的 某个类或者某个一个方法，只有一处用到了，但是这个方法的流程特别多，做的事业特别多，那么就
2021-08-04 18:56:58
123
原创 2. 依赖倒置原则
还是来看 《spring5核心与手写30个类》一书 的简短定义（以后不引用出处了，有机会把觉得不错的书给大家分享一下就好了） 作者说的我是说不出来，介绍一个类似的词，在编程接界中有个很装逼但是其实很简单的词汇：代码入侵，啥是代码入侵呢：就是低游模块引入了高层模块的代码，构成了相互依赖，或者逆向依赖。比如说正常A模块是功能入口方法，B模块是支持A工作的服务方，正常是A调用B的模块，但是在B模块又调用了A模块的方法，那A就对B造成了入侵，正常B是不应该调用A的，B只能被A调用。 其实个人理解只要不出现代码
2021-08-04 18:18:04
107
原创 1.开闭原则
开闭原则，看一下由 《spring5 核心原理与30个类手写实战》 一书给出的定义： 核心的几句话就是： 对修改关闭， 对扩展开放。 如何做到对修改关闭， 对扩展开放呢？首先解释一下这段话 解释： 用白话就是，当产品经理又改需求了，或者添加了新功能，如果变化特别大，那我们最好做到尽可能少甚至不修改原来的逻辑代码，通过扩展功能代码替换原逻辑。 如何做到：那么怎么通过扩展替换原来的逻辑呢？就是用到面向接口编程 。 给大家讲一个业务： 张三同学开学了，学校规定：同学们的书都是学校老师采购的，老
2021-08-04 17:25:44
104
elasticsearch-6.2.4.tar.gz与kibana-6.2.4-linux-x86_64.tar.gz
2019-04-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人