java的几种设计模式简介
https://www.cnblogs.com/zhaojinyan/p/9401010.html
java的设计模式大体上分为三大类:
- 创建型模式(5种):工厂方法模式,抽象工厂模式,单例模式,建造者模式,原型模式。
- 结构型模式(7种):适配器模式,装饰器模式,代理模式,外观模式,桥接模式,组合模式,享元模式。
- 行为型模式(11种):策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
设计模式遵循的原则有6个:
-
1、开闭原则(Open Close Principle)
对扩展开放,对修改关闭。 -
2、里氏代换原则(Liskov Substitution Principle)
只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。 -
3、依赖倒转原则(Dependence Inversion Principle)
这个是开闭原则的基础,对接口编程,依赖于抽象而不依赖于具体。 -
4、接口隔离原则(Interface Segregation Principle)
使用多个隔离的借口来降低耦合度。 -
5、迪米特法则(最少知道原则)(Demeter Principle)
一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。 -
6、合成复用原则(Composite Reuse Principle)
原则是尽量使用合成/聚合的方式,而不是使用继承。继承实际上破坏了类的封装性,超类的方法可能会被子类修改。
java设计模式详情
1、工厂模式(Factory Method)
常用的工厂模式是静态工厂,利用static方法,作为一种类似于常见的工具类Utils等辅助效果,一般情况下工厂类不需要实例化。
2、抽象工厂
一个基础接口定义了功能,每个实现接口的子类就是产品,然后定义一个工厂接口,实现了工厂接口的就是工厂,这时候,接口编程的优点就出现了,我们可以新增产品类(只需要实现产品接口),只需要同时新增一个工厂类,客户端就可以轻松调用新产品的代码。
抽象工厂的灵活性就体现在这里,无需改动原有的代码,毕竟对于客户端来说,静态工厂模式在不改动StaticFactory类的代码时无法新增产品,如果采用了抽象工厂模式,就可以轻松的新增拓展类。
3、单例模式
实现单例的四个原则:
-
1.构造私有。
-
2.以静态方法或者枚举返回实例。
-
3.确保实例只有一个,尤其是多线程环境。
-
4.确保反序列换时不会重新构建对象。
我们常用的单例模式有:
-
饿汉模式:饿汉模式在类被初始化时就已经在内存中创建了对象,以空间换时间,故不存在线程安全问题。
-
懒汉模式:懒汉模式在方法被调用后才创建对象,以时间换空间,在多线程环境下存在风险。
-
双重锁懒汉模式:只有在对象需要被使用时才创建,第一次判断 INSTANCE == null为了避免非必要加锁,当第一次加载时才对实例进行加锁再实例化。这样既可以节约内存空间,又可以保证线程安全。但是,由于jvm存在乱序执行功能,DCL也会出现线程不安全的情况。
具体分析如下:
INSTANCE = new SingleTon();这个步骤,其实在jvm里面的执行分为三步:
1.在堆内存开辟内存空间。
2.在堆内存中实例化SingleTon里面的各个参数。
3.把对象指向堆内存空间。由于jvm存在乱序执行功能,所以可能在2还没执行时就先执行了3,如果此时再被切换到线程B上,由于执行了3,INSTANCE 已经非空了,会被直接拿出来用,这样的话,就会出现异常。这个就是著名的DCL失效问题。
不过在JDK1.5之后,官方也发现了这个问题,故而具体化了volatile,即在JDK1.6及以后,只要定义为private volatile static SingleTon INSTANCE = null;就可解决DCL失效问题。volatile确保INSTANCE每次均在主内存中读取,这样虽然会牺牲一点效率,但也无伤大雅。
-
静态内部类模式
静态内部类的优点是:外部类加载时并不需要立即加载内部类,内部类不被加载则不去初始化INSTANCE,故而不占内存。即当SingleTon第一次被加载时,并不需要去加载SingleTonHoler,只有当getInstance()方法第一次被调用时,才会去初始化INSTANCE,第一次调用getInstance()方法会导致虚拟机加载SingleTonHoler类,这种方法不仅能确保线程安全,也能保证单例的唯一性,同时也延迟了单例的实例化。
那么,静态内部类又是如何实现线程安全的呢?首先,我们先了解下类的加载时机。
类加载时机:JAVA虚拟机在有且仅有的5种场景下会对类进行初始化。
1.遇到new、getstatic、setstatic或者invokestatic这4个字节码指令时,对应的java代码场景为:new一个关键字或者一个实例化对象时、读取或设置一个静态字段时(final修饰、已在编译期把结果放入常量池的除外)、调用一个类的静态方法时。
2.使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没进行初始化,需要先调用其初始化方法进行初始化。
3.当初始化一个类时,如果其父类还未进行初始化,会先触发其父类的初始化。
4.当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的类),虚拟机会先初始化这个类。
5.当使用JDK 1.7等动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。
这5种情况被称为是类的主动引用,注意,这里《虚拟机规范》中使用的限定词是"有且仅有",那么,除此之外的所有引用类都不会对类进行初始化,称为被动引用。静态内部类就属于被动引用的行列。
- 枚举模式
用enum实现Singleton时我曾介绍过三个特性,自由序列化,线程安全,保证单例
建造者模式(builder)
网上参考
例子参考
主要作用就是将复杂事物创建的过程抽象出来,该抽象的不同实现方式不同,创建出的对象也不同。
简介
1、定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示
2、主要作用:在用户不知道对象的建造过程和细节的情况下就可以直接创建复杂的对象。
3、如何使用:用户只需要给出指定复杂对象的类型和内容,建造者模式负责按顺序创建复杂对象(把内部的建造过程和细节隐藏起来)
4、解决的问题:
(1)、方便用户创建复杂的对象(不需要知道实现过程)
(2)、代码复用性 & 封装性(将对象构建过程和细节进行封装 & 复用)
5、注意事项:与工厂模式的区别是:建造者模式更加关注与零件装配的顺序,一般用来创建更为复杂的对象
优缺点总结
-
(1)优点
1、产品的建造和表示分离,实现了解耦。
2、将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰
3、增加新的具体建造者无需修改原有类库的代码,易于拓展,符合“开闭原则“。
-
(2)缺点
1、产品必须有共同点,限制了使用范围。
2、如内部变化复杂,会有很多的建造类,难以维护。
应用场景
1、需要生成的产品对象有复杂的内部结构,这些产品对象具备共性;
2、隔离复杂对象的创建和使用,并使得相同的创建过程可以创建不同的产品。
3、需要生成的对象内部属性本身相互依赖。
4、适合于一个具有较多的零件(属性)的产品(对象)的创建过程。
原型模式(Protype)
网上参考详情
在java中我们知道通过new关键字创建的对象是非常繁琐的(类加载判断,内存分配,初始化等),在我们需要大量对象的情况下,原型模式就是我们可以考虑实现的方式。
原型模式我们也称为克隆模式,即一个某个对象为原型克隆出来一个一模一样的对象,该对象的属性和原型对象一模一样。而且对于原型对象没有任何影响。原型模式的克隆方式有两种:浅克隆和深度克隆
原型模式 | 说明 |
---|---|
浅克隆 | 只是拷贝本对象,其对象内部的数组、引用对象等都不拷贝,还是指向原生对象的内部元素地址 |
深度克隆 | 深复制把要复制的对象所引用的对象都复制了一遍 |
6.适配器模式(Adapter)
适配器模式的概念
适配器模式,将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适配器模式主要用于解决的问题是需要的东西就在面前,但却不能使用,而短时间无法改造它,于是就想办法去适配的,具体的在使用场景例子在后面给出
适配器模式的作用就是在原来的类上提供新功能。主要可分为3种:
现实开发中需要借助:RMI已经帮我们做好了,只要有接口,就可以远程的对象当成本地的对象使用
- 类适配:创建新类,继承源类,并实现新接口,使用继承,例如:
类的适配器参考class adapter extends oldClass implements newFunc{ //可能需要将远程的对象强转为本地的String }
- 对象适配:创建新类持源类的实例,并实现新接口,使用组合,例如
class adapter implements newFunc { //对象通过构造器引入进来 private oldClass oldInstance ; }
- 接口适配:创建新的抽象类实现旧接口方法。例如
abstract class adapter implements oldClassFunc { void newFunc();}
适配器的缺省
适配器的缺省模式就是写一个默认的适配器去实现目标接口中的所有方法,然后在开发中,你所需要的对象,只需要继承默认的适配器,然后实现你所需要的方法。
适配器模式的优缺点:
-
1.优点:
1)将目标类和适配者类解耦
2)增加了类的透明性和复用性,将具体的实现封装在适配者类中,对于客户端类来说是透明的,而且提高了适配者的复用性
3)灵活性和扩展性都非常好,符合开闭原则 -
2.类适配器还有的优点:
由于适配器类是适配者类的子类,因此可以再适配器类中置换一些适配者的方法,使得适配器的灵活性更强。 -
3.类适配器的缺点:
对于Java、C#等不支持多重继承的语言,一次最多只能适配一个适配者类,而且目标抽象类只能为接口,不能为类,其使用有一定的局限性,不能将一个适配者类和他的子类同时适配到目标接口 -
4.对象适配器还有的优点:
把多个不同的适配者适配到同一个目标,也就是说,同一个适配器可以把适配者类和他的子类都适配到目标接口。 -
5.对象适配器的缺点:
与类适配器模式相比,要想置换适配者类的方法就不容易。
适配器模式的适用场景
系统需要适用适用现有的类,而此类的接口不符合系统的要求。
适配器模式与桥梁模式的关系
当一个客户端只知道一个特定的接口,但是又必须与具有不同接口的类打交道时,就应该使用适配器模式。桥梁模式的用意是要把实现和它的接口分开,以便它们可以独立地变化。桥接模式并不是用来把一个已有的对象接到不匹配的接口上。
适配器模式与装饰模式的关系
装饰模式和适配器模式都是“包装模式(Wrapper Pattern),它们都是通过封装其他对象达到设计的目的的,但是它们的形态有很大区别。
理想的装饰模式在对被装饰对象功能增强的同时,要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而,适配器则不然,一般而言,适配器模式并不要求对源对象的功能进行增强,但是会改变源对象的接口,以便和目标接口相符合。
装饰模式(Decorator)
装饰模式的概念
装饰(Decorator)模式又名包装(Wrapper)模式。装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案。简单的说,就是给一类对象增加新的功能,装饰方法与具体的内部逻辑无关。
装饰模式有透明和半透明两种。这两种的区别就在于装饰角色的接口与抽象构件角色的接口是否完全一致
在装饰模式中的角色有:
- 抽象构件(Component)角色:给出一个抽象接口,以规范准备接收附加责任的对象。
- 具体构件(ConcreteComponent)角色:定义一个将要接收附加责任的类。
- 装饰(Decorator)角色:持有一个构件(Component)对象的实例,并定义一个与抽象构件接口一致的接口。
- 具体装饰(ConcreteDecorator)角色:负责给构件对象“贴上”附加的责任。
透明性的要求
装饰模式对客户端的透明性要求不要声明一个ConcreteComponent(具体构件)类型的变量,而应当声明一个Component(抽象构件)类型的变量。
装饰模式的优点
(1)装饰模式与继承关系的目的都是要扩展对象的功能,但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”,或者除掉一个不需要的“装饰”。继承关系则不同,继承关系是静态的,它在系统运行前就决定了。
(2)通过使用不同的装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
装饰模式的缺点
由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另一方面,使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得差错变得困难,特别是这些对象看上去都很相像。
例如:
半透明的装饰模式
半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口,也可以通过改写一个或几个方法,或增加新的方法来增强或改变所考虑的类的功能。大多数的装饰模式实际上是半透明的装饰模式,这样的装饰模式也称作半装饰、半适配器模式。
Component c = new ConcreteComponent();
代理模式(Proxy)
客户端通过代理类访问,代理类实现具体的实现细节,客户只需要使用代理类即可实现操作。
这种模式可以对旧功能进行代理,用一个代理类调用原有的方法,且对产生的结果进行控制。
interface Source{ void method();}
class OldClass implements Source{
@Override
public void method() {
}
}
class Proxy implements Source{
private Source source = new OldClass();
void doSomething(){}
@Override
public void method() {
new Class1().Func1();
source.method();
new Class2().Func2();
doSomething();
}
}
外观模式(Facade)
为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用。这句话是百度百科的解释,有点难懂,但是没事,看下面的例子,我们在启动停止所有子系统的时候,为它们设计一个外观类,这样就可以实现统一的接口,这样即使有新增的子系统subSystem4,也可以在不修改客户端代码的情况下轻松完成。
复制代码