Android 设计模式
参考:
https://www.cnblogs.com/qlky/p/7328003.html
-
单例模式
定义:确保单例类只有一个实例,并且这个单例类提供一个函数接口让其他类获取到这个唯一的实例
用途:创建时消耗太多资源或者是new的代价比较大
实现:
/** * Writer:GuoWei_aoj on 2019/3/8 0008 16:00 * description:单例模式 * 常用到的有:application ,获取WindowManager服务引用 */ class Singleton { //线程每次使用到被volatile关键字修饰的变量时,都会去堆里拿最新的数据 private volatile static Singleton singleton = null; private Singleton(){} public static Singleton getInstance(){ //避免不必要的同步 if (singleton==null){ synchronized (Singleton.class){ //确保之前没有其他线程进入到sychronized创建实例 if (singleton==null){ singleton = new Singleton(); } } } return singleton; } } //----------------------------使用------------------------------------------- Singleton singleton = Singleton.getInstance();
注意:
- 可能会造成的内存泄漏,持有Activity的引用
-
Builder
定义:将一个复杂对象的构造与它的表示分离,使得同样的构造过程可以创建不同的表示
用途:Dialog,封装popupwindow
实现:
/** * Writer:GuoWei_aoj on 2019/3/8 0008 16:20 * 1. description:Builder模式---同样的构造过程可以创建不同的表示 * 2. 解决参数之间有依赖关系 不必按照顺序设置参数 * 3. 链式调用 */ public class Builder { private int id; private String num; BuilderData build(){ BuilderData builderData = new BuilderData(); builderData.setId(id); builderData.setNum(num); return builderData; } public Builder setId(int id){ this.id = id; return this; } Builder setNum(String num){ this.num = num; return this; } } //--------------------------------------------------------------------- public class BuilderData { private int id; private String num; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getNum() { return num; } public void setNum(String num) { this.num = num+id; } @Override public String toString() { return "BuilderData{" + "id=" + id + ", num='" + num + '\'' + '}'; } } //--------------------------------使用------------------------------------- BuilderData builderData = new Builder().setId(1).setNum("g").build();
-
原型模式
定义:将一个对象进行拷贝
用途:类的属性特别多,但是又要经常对类进行拷贝的时候可以用
实现:
Uri uri=Uri.parse("smsto:10086"); Intent shareIntent=new Intent(Intent.ACTION_SENDTO,uri); Intent intent=(Intent)shareIntent.clone(); startActivity(intent);
注意:深浅拷贝
-
工厂模式
定义:最常用的实例化对象模式
用途:你需要实例化一个对象,你发现不止一个选择(所有供选择的类都实现了同一个接口)的时候,针对这一情况写一个通用的方法(方法返回类型是那个共用的接口),这就是工厂模式了
实现:
public abstract class Product{ public abstract void method(); } public class ConcreteProductA extends Prodect{ public void method(){ System.out.println("我是产品A!"); } } public class ConcreteProductB extends Prodect{ public void method(){ System.out.println("我是产品B!"); } } public abstract class Factory{ public abstract Product createProduct(); } public class MyFactory extends Factory{ public Product createProduct(){ return new ConcreteProductA(); } }
注意:
- 使用工厂类不必考虑产品是什么创建的,直接使用对象就行。
- 违反了高内聚责任分配原则 ,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
-
抽象工厂
定义:为创建一组相关或者相互依赖的对象提供一个接口,而无需指定它们的具体类。
用途:生产多个产品组合的对象时 (组装电脑-cpu-memory-hd)
实现:
AbstractProduct(抽象产品类):定义产品的公共接口。 ConcreteProduct(具体产品类):定义产品的具体对象,实现抽象产品类中的接口。 AbstractFactory(抽象工厂类):定义工厂中用来创建不同产品的方法。 ConcreteFactory(具体工厂类):实现抽象工厂中定义的创建产品的方。 //反正组合就行了 //抽象产品类-- CPU public abstract class CPU { public abstract void showCPU(); } //抽象产品类-- 内存 public abstract class Memory { public abstract void showMemory(); } //抽象产品类-- 硬盘 public abstract class HD { public abstract void showHD(); } //抽象工厂类,电脑工厂类 public abstract class ComputerFactory { public abstract CPU createCPU(); public abstract Memory createMemory(); public abstract HD createHD(); } //剩下的就是子类继承,然后随便组合吧
注意:
- 创建实例的工作与使用实例的工作分开,使用者不必关心类对象如何创建。
- 如果增加新的产品,则修改抽象工厂和所有的具体工厂,违反了开放封闭原则
- 工厂模式是一个工厂只能对应生产一个产品,工厂方法具有唯一性
- 抽象工厂模式则可以提供多个产品对象,而不是单一的产品对象。
-
策略模式
定义:定义一系列的算法,把每一个算法封装起来,并且使它们可相互替换。策略模式模式使得算法可独立于使用它的客户而独立变化。
用途:
- 同一个问题具有不同算法时,即仅仅是具体的实现细节不同时,如各种排序算法等等。
- 对客户隐藏具体策略(算法)的实现细节,彼此完全独立;提高算法的保密性与安全性。
- 一个类拥有很多行为,而又需要使用if-else或者switch语句来选择具体行为时。使用策略模式把这些行为独立到具体的策略类中,可以避免多重选择的结构。
实现:
Stragety(抽象策略类):抽象类或接口,提供具体策略类需要实现的接口。 ConcreteStragetyA、ConcreteStragetyB(具体策略类):具体的策略实现,封装了相关的算法实现。 Context(环境类):用来操作策略的上下文环境。 //以追妹纸为例,遇到不同的妹纸追求的套路(策略)是不一样的。 //ListView 设置不同的Adapter //动画中的插值器(ValueAnimator 的 setInterpolator 方法)
注意:
- 因为所有策略都是实现的同一个接口,所以不同的策略可以相互替换
- 耦合度低,方便扩展 ,每次有了新策略,就可以加一个类就行,符合开闭原则
- 避免在逻辑代码中使用多重选择语句
- 策略多了,子类也会增多
- 用户需要知道所有的策略,来确定到底是使用哪一种