java的debug类型_javaDebug

UML

▬▶

┈┈＞

继承→

▬▷

┈▷

┈▶

♢→

♦→

UML关系

子类指向父类

实体指向接口

继承关系

类与类之间的关系

is a的关系;

鸟是动物;

实线空心箭头;

鸟▬▷动物

实现关系

类与接口之间的关系;

虚线空心箭头表示;

大雁实现了飞翔接口;

大雁┈▷飞翔

依赖关系

一般是方法的参数,返回值体现在方法上;

虚线箭头;

动物依赖氧气;

动物┈┈＞氧气

关联关系

实线箭头,一个类作为另一个类的属性

聚合关系

整体和局部的关系,拥有独立的生命周期

以空心菱形开始的实线箭头表示(菱形部分是组成单位)比如大雁聚合成大雁群(♢→)

组合关系

整体和局部的关系,拥有相同的生命周期

以实心菱形开始的实线箭头表示(菱形部分是组成单位)比如鸟的翅膀(翅膀♦→鸟)

7大设计原则

开闭原则

一个软件实体(类,模块和函数)应该对扩展开放,对修改关闭;

强调用抽象构建框架,用实现扩展细节;

优点:提高复用性和可维护性;

依赖倒置原则

高层模块不应该依赖低层模块,二者都应该依赖其抽象;

抽象不应该依赖细节,细节应该依赖抽象;

针对接口编程,不要针对实现编程;

优点:可以减少类之间的耦合性,提高系统稳定性,提高代码可读性和可维护性,可降低修改程序造成的危险.

单一职责原则

不要存在多余一个导致类变更的原因;

一个类/接口/方法只负责一项职责;

优点:降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险

接口隔离原则

用多个专门的接口,而不使用单一的总接口,客户端不应该依赖他不需要的接口;

一个类对一个类(包括接口)的依赖应该建立在最小的接口上;

建立单一接口,不要建立庞大臃肿的接口;

尽量细化接口,接口中的方法尽量少;

注意适度原则,一定要适度;

优点:符合我们常说的高内聚低耦合的特点,使类具有很好的可读性,可扩展性和可维护性

接口隔离原则与单一职责原则的区别

单一职责原则指的是类,方法,接口的职责是单一的,强调的是职责,在一个接口里只要职责是单一的,有多个方法也可以;针对的是程序的实现和细节;

接口隔离注重的是对接口依赖的隔离,主要约束的是接口,针对程序框架的构建

接口尽量小可以但是要有限度,太小的话,接口数量过多设计越复杂

提高内聚,减少对外的交互,使接口以最少的方法实现更多的功能

迪米特法则(最少知道原则)

一个对象应该对其他对象保持最少的了解,又叫最少知道原则

尽量降低类与类之间的耦合

优点:降低类与类之间的耦合

强调只和朋友交流不合陌生人说话

朋友:出现在成员变量,方法的输入输出参数中的类称为成员的朋友类,出现在方法体内部的类不属于朋友类

不要对外公开太多的public方法和public静态变量,尽量使用private和protected访问权限

里氏替换原则

如果对于每一个类型为T1的对象o1都有类型为t2的对象o2;使得以t1定义的所有程序P在所有对象o1都替换成o2时,程序P的行为没有发生变化,那么类型t2是类型t1的子类型

定义扩展:

一个软件实体如果适用一个父类的话,那他一定适用于其子类,所有引用父类的地方必须能透明的使用其子类对象,子类对象能替换父类对象,而程序的逻辑不变

引申意义:

子类可以扩展父类的功能,但不能改变父类原有的功能

含义1:

子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法

含义2:子类可以增加自己特有的方法

含义3: 当子类方法重载父类方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松(比如父类使用Hashmap子类可使用Map)

含义4:当子类实现父类的方法时(重写/重载或实现抽象方法),方法的后置条件(即方法的输出/返回值)要比父类严格或相等

优点1:约束继承泛滥,是开闭原则的一种体现

优点2:加强程序的健壮性,同时变更时也可以做到非常好的兼容性,提高程序的维护性扩展性.降低需求变更时引入的风险

里氏替换原则是对开闭原则的补充,表达了反对子类重写替换父类的行为

合成/复用原则(组合/复用原则)

定义:尽量使对象组合/聚合,而不是继承关系达到软件复用的目的

聚合是has a的的关系

组合是contains a的关系

优点:可以使系统更加灵活.降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少

黑箱复用: 组合/聚合,A类中包含B类,对于B的具体实现细节A是看不到的

白箱复用:继承,父类的实现细节全部暴露给了子类(父类的实现发生改变,子类使用父类的实现后就不得不发生改变)

设计模式

创建型模式

简单工厂模式

定义

由一个工厂对象决定创建出哪种产品类的实例

属于创建型但不属于GOF23种设计模式

适用场景

1.工厂类负责创建的对象比较少;

2.客户端(应用层)只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心

优点

只需要传入一个正确的参数就可以获取你所需要的对象,无需知道其创建细节

缺点

工厂的职责相对过重,增加新产品需要修改工厂类的判断逻辑,违背了开闭原则

无法形成基于继承的等级结构

工厂方法模式

定义

定义一个创建对象的接口,但让实现这个接口的类来决定实例化哪个类

工厂方法让类的实例化推迟到子类中进行

使用场景:

创建对象需要大量重复的代码

客户端(应用层)不依赖于产品类实例如何被创建,实现等细节

3.一个类通过其子类来指定创建哪个对象

优点:

用户只需关心所需产品对应的工厂,无需关心创建细节.

加入新产品符合开闭原则,提高扩展性

缺点:

类的个数容易过多,增加复杂度

增加了系统抽象性和理解难度

抽象工厂模式

定义

抽象工厂模式提供了一个创建一系列相关或相关依赖对象的接口

无需指定他们具体的类

将一组对象的实现细节和使用分隔开

适用场景:

客户端(应用层)不依赖于产品实例如何被创建,实现等细节

强调一系列相关的产品对象(属于同一产品族)一起使用创建对象需要大量重复代码

3.提供一个产品类的库.所有的产品以同样的接口出现,从而使客户端不依赖于具体实现

优点:

具体代码在应用层代码隔离,无需关心创建细节

将一个系列的产品族放到一起创建

缺点:

规定了所有可能被创建的产品集合,产品族中扩展新的产品困难,需要修改抽象工厂的接口

增加了系统的抽象性和理解难度

建造者模式

####定义

将一个复杂对象的构建吗与他的表示分离,使得同样的构建过程可以创建不同的表示

用户只需要指定需要建造的类型就可以得到他们,建造过程及细节不需要知道

适用场景

如果一个对象有非常复杂的内部结构(很多属性)

想把复杂的对象的创建和使用分离

优点

封装性好,创建和使用分离

扩展性好,建造类之间独立,一定程度上解耦

缺点

产生多余的Builder对象

产品内部发生变化,建造者都要修改,成本较大

单例模式

定义

保证一个类仅有一个实例,并提供全局访问点

适用场景

确保任何情况下都绝对只有一个实例

(线程池,数据库连接)

优点

1.在内存里只有一个实例,减少了内存开销

2.了以避免对资源的多重占用(多线程读取同一个文件)

3.设置全局访问点.严格控制访问

缺点

没有接口,扩展困难

要点

私有构造器

线程安全

延迟加载

序列化和反序列化安全

反射

原型模式

行为型模式

策略模式

观察者模式

责任链模式

备忘录模式

模板方法模式

迭代器模式

中介者模式

命令模式

访问者模式

解释器模式

状态模式