- 博客(27)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 JAVA集合
概述集合包含两种容器结构：Collection，Map。Collection下面有Set，List，Queue三种接口。Set下面有HashSet，LinkedHashSet，TreeSet。List下面主要有ArrayList，LinkedList，Vector。Queue下面有PriorityQueue。Map下面有HashMap，TreeMap，HashTable，LinkedHashMap。Collection继承了Iterable接口，因此Collection下的实现类都可以通过迭
2021-01-31 16:44:22
124
原创 java对象比较
概述比较分为值比较和引用类型比较。值比较即内容相同，我们就认为是相等的。比如：int i=5；int j =5；此时我们说i和j相等，其实指的是i和j的内容相同。引用类型比较两个对象的引用使用==等号比较，是指引用指向的内存地址是否相等，而不是两个对象的内容是否相等。Student a = new Student(); Student b = new Student();a == b -> false这里的比较是堆中的两个对象的内存地址是否相同。Student a = new S
2021-01-27 23:39:48
185
原创 红黑树
左右旋转定义左旋以某个节点的位置作为选择轴，该节点向左侧逆时针旋转，因此该节点的右节点被拉到该节点之前的位置，旋转结束；该节点的父节点成为该节点右孩子的父节点，该节点成为右节点的左子节点，右节点之前的左孩子成为该节点的右孩子。右旋以某个节点的位置作为旋转轴，该节点向右侧顺时针旋转，因此该节点的左节点被拉到该节点之前的位置，旋转结束；该节点的父节点成为该节点左孩子的父节点，该节点成为左节点的右子节点，左节点之前的右孩子成为该节点的左孩子。左右旋源码左旋参考https://b
2021-01-27 22:00:43
160
原创 2-3-4树与红黑树
概述234树和红黑树是完全等价的，红黑树本质上就是234树；由于234树是一棵高度平衡的树，实现起来比较复杂，所以一般通过红黑树来实现234树，而红黑树同样保证了O(logN)的时间内完成查找、插入和删除操作。红黑树的定义节点只能是黑色或者红色。根节点必须是黑色。每个叶子节点是黑色节点（称之为NIL节点，又被称为黑哨兵）；可以理解为红黑树中每个节点都有两个子节点，除了黑色的空节点。每个红色节点的两个子节点都是黑色（或者说从每个叶子节点到根的所有路径上不能有两个连续的红色节点）。从任一节点到它
2021-01-25 23:07:40
858
1
原创 Java学习路线
概述可以按时间轴大致分为以下几大块。Java基础Java高级（重点）JavaWeb研发工具主流框架分布式、微服务、并行架构运维知识DevOps大数据技术项目总结大厂面试题编程基础扩展成神之路平稳降落具体阶段分解Java基础基础语法面向对象封装继承多态数组JavaApi如何调用如何查看API文档异常处理集合泛型I/O反射注解网络通信Java高级（重点）Java多线程/高并发并发基础互斥同步非阻塞同步
2021-01-17 23:26:42
231
2
原创 设计模式总结
主要目标管理变化，提供复用！两个手段分解把具体的功能先拆分。抽象把公共的部分提取出来形成抽象的部分，统一处理。九大原则依赖倒置（DIP）开闭原则（OCP）单一职责（SRP）里氏替换（LSP）接口隔离（ISP）组合复用迪米特法则封装变化点面向接口编程重构技法静态 -> 动态早绑定 -> 晚绑定继承 -> 组合编译时依赖 -> 运行时依赖紧耦合 -> 松耦合封装变化角度对模式分类组件协作Template Metho
2021-01-16 17:29:35
152
原创 解析器模式-设计模式
动机在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解析器来解释这样的句子，从而达到解决问题的目的。模式定义给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。类图总结Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的结构不断重复出现，
2021-01-16 15:55:25
323
原创 访问者模式-设计模式
动机在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？模式定义表示一个作用与某对象结构中的各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用于这些元素的新操作（变化）。备注：访问者是把操作数据结构的行为和数据拆分；前提是数据结构稳定不变，无法预知以后
2021-01-16 13:27:27
164
原创 命令模式-设计模式
动机在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合一一比如需要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。模式定义将一个请求（行为）封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。类图实例...
2021-01-13 21:29:01
198
1
原创 职责链模式-设计模式
动机在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能由一个接受者，如果显示指定，将比不可少的带来发送者和接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。模式定义是多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。...
2021-01-11 21:40:24
134
原创 迭代器模式-设计模式
动机在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种“透明遍历”也为“同一种算法在多种集合上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式。模式定义提供一种方法顺序访问一种聚合对象中的各个元素，而又不暴露（稳定）该对象的内部表示。类图要点总结迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。迭代多态：为
2021-01-11 21:17:58
118
原创 组合模式-设计模式
动机在软件某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。如何将“客户代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？模式定义将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。类图总结Composite模式采用树形结构来实现普遍存在
2021-01-11 20:53:57
151
原创 备忘录模式-设计模式
动机在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，变化暴露对象的细节实现。如何实现对象状态的良好保存于恢复？但同时又不会因此而破坏对象本身的封装性。模式定义在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。...
2021-01-10 21:51:03
125
原创 状态模式-设计模式
动机在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转换间引入紧耦合？模式定义允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。重点是提取出影响每种状态变化的行为；每种状态负责切换到下一个正确的状态，状态类自己管理自己的状态切换。类图总结State模式将所有与一个特定状态相关的行为都放入一个
2021-01-10 20:28:28
138
原创 中介者模式-设计模式
动机在软件构建过程中，经常会出现多个对象互相管理交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。模式定义用一个中介对象来封装（封装变化）一系列的对象交互。中介者是各对象不需要显示的相互引用（编译时依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变他们之间的交互。类图不同类在使用中
2021-01-09 22:02:40
175
原创 适配器模式-设计模式
动机在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所需求的接口？模式定义将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。类图总结Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方法非常
2021-01-09 21:24:50
154
原创 代理模式-设计模式
动机在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构代理很多麻烦。如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层接口是软件开发中常见的解决方式。模式定义为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。类图总结“增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的Proxy对象
2021-01-09 17:41:23
156
1
原创 门面模式-设计模式
动机解决系统对外的复杂度的问题，添加一个间接层统一对外提供服务，简化了外部系统和内部系统之间的交互。A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦?模式定义为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口这个接口使得这一子系统更加容易使用（复用）。类图实例门面模式代
2021-01-09 15:29:09
204
1
原创 享元模式-设计模式
动机在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价—主要指内存需求方面的代价。如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？模式定义运用共享技术有效地支持大量细粒度的对象。类图实例场景：通过字体的显示问题，来描述享元模式的问题，考虑的字体是非常细粒度的对象，同时也是大量存在的，使用享元模式可以提高程序的性能。注意享元模式和单例模式强调的是性能，不强调抽象，因此我们会看到类中会有具体的类
2021-01-09 14:31:11
197
原创 单例模式-设计模式
动机在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。如何绕过常规的构造器，提供一种机制来保证一个类只要一个实例？这应该是类设计者的责任，而不是使用者的责任。模式定义保证一个类仅有一个实例，并提供一个该实例的全局访问点。类图总结Singleton模式中的实例构造器可以设置为protected已允许子类派生。Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleto
2021-01-09 13:44:51
214
原创 构建器模式-设计模式
动机在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常有各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？模式定义将一个复杂对象的构建与表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）。类图总结Builder模式主要用于“分步骤构建一个复杂的对象”
2021-01-06 21:20:26
1427
1
原创 原型模式-设计模式
动机（prototype）在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却由于比较稳定一致的接口。如何应对这种变化？如何向“客户程序（使用这些对象的程序）”隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变。模式定义使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。注释通过对象比较复杂，初始化状态不符合条件，可以通过拷贝原型的方式，把一个达到理想状态的对象拷贝构造成一个新对象
2021-01-05 22:51:58
143
原创 桥模式-设计模式
动机由于某些类型的固有的实现逻辑，使得他们具有两个变化的维度，乃至多个维度的变化。如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？实例场景：一个Message系统，系统中有一些公共方法，分别由PC和Mobile两个产品，同时每个产品又有精简版和完美版。没有使用桥模式之前没有稳定的framework供用户调用，代码没有做到开闭原则；同时代码重复率过高，不符合组合复用原则。定义消息抽象类public abstrac
2021-01-04 22:52:50
661
原创 装饰模式-设计模式
装饰器模式在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引人的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态的实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？...
2021-01-02 12:42:19
263
原创 抽象工厂模式-设计模式
动机在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？模式定义提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。类图总结如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。“系列对象”
2021-01-02 00:01:40
140
springcloud-feign.zip
2021-06-17
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人