Android工厂设计模式(简单工厂，工厂方法，抽象工厂，BitmapFactory简单工厂分析，Retrofit抽象工厂分析)

文章目录

创建型设计模式(简单工厂，工厂方法，抽象工厂)
- 一.简单工厂模式
- - 引出简单工厂模式
- 二.工厂方法模式
- 三.抽象工厂模式
Android源码中用到的工厂模式举例
- 一.BitmapFactory 源码工厂模式详解(简单工厂)
- 二.Retrofit的工厂模式(抽象工厂)

创建型设计模式(简单工厂，工厂方法，抽象工厂)

工厂模式主要是用于对对象实例化的一种管理模式，一般情况下，我们都需要使用new关键字来创建一个对象，那么我们就需要用工厂模式来统一管理我们对象的创建过程，把对象的创建交给该模式去处理，这样我们就不用手动的去new对象了，工厂模式主要是将创建对象的具体过程屏蔽隔离起来。

首先我们先来看一个Android里面开发常用的例子SharedPreferences。这是布局文件

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"xmlns:app="http://schemas.android.com/apk/res-auto"xmlns:tools="http://schemas.android.com/tools"android:layout_width="match_parent"android:layout_height="match_parent"tools:context=".simple1.MainActivity"><TextViewandroid:id="@+id/infoTv"android:onClick="getInfo"android:layout_width="wrap_content"android:layout_height="wrap_content"android:text="Hello World!"app:layout_constraintBottom_toBottomOf="parent"app:layout_constraintEnd_toEndOf="parent"app:layout_constraintStart_toStartOf="parent"app:layout_constraintTop_toTopOf="parent" /></androidx.constraintlayout.widget.ConstraintLayout>

我们一般都这么写，常规写法

public class MainActivity extends AppCompatActivity {TextView textView;private SharedPreferences preferences;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);textView = findViewById(R.id.infoTv);//模拟用SP存入数据SPUtils.getInstance().putString("username", "Colin").putString("userAge", "33").commit();}//这里是模拟从SP取出我们想要的数据展示在UI上public void getInfo(View view) {String username = SPUtils.getInstance().getString("username", "");String userAge = SPUtils.getInstance().getString("userAge", "");textView.setText("username=" + username + "userAge=" + userAge);}
}

SP工具类

public class SPUtils {private SharedPreferences.Editor editor;private SharedPreferences preferences;private volatile static SPUtils mInstance;private SPUtils() {}public static SPUtils getInstance() {if (mInstance == null) {synchronized (SPUtils.class) {if (mInstance == null) {mInstance = new SPUtils();}}}return mInstance;}public void init(Context context) {preferences = context.getSharedPreferences("Cache", Context.MODE_PRIVATE);editor = preferences.edit();}public SPUtils putString(String key, String value) {editor.putString(key, value);return this;}public void commit() {editor.commit();}public String getString(String key, String defaultStr) {return preferences.getString(key, defaultStr);}
}

初始化

public class MyApp extends Application {@Overridepublic void onCreate() {super.onCreate();SPUtils.getInstance().init(this);}
}

小结：

优点：通过SPUtils工具类来优化代码，就不用每次都在Activity里面重复写SP的代码了，做到了统一管理。

缺点：不能灵活改变获取数据的方式。数据如果更换成内存，或者数据库，MMKV的方式存取，那么就要将上面用到SP的地方都换掉，换成内存换成，数据库的方式存储的话，那么我们需要改动的代码就很多。

一.简单工厂模式

其实我觉得简单工厂模式是一种书写的思维习惯，不太像真实的软件设计模式。

由上面的例子引出下面这幅图。假设我们有4中方式操作数据，那么我们复写4份不同的代码，那就很无语了；那么我们可以定义一套规则，有写入数据，取出数据的操作，然后再交给不同方式的不同对象去处理就好。


/**
定义好写入数据和读取数据的接口，类似于一种规则，
都是我们常见的数据类型，
*/
public interface IOHandler {//写数据void put(String key, String value);void put(String key, int value);void put(String key, long value);void put(String key, boolean value);void put(String key, Object value);void put(String key, double value);void put(String key, float value);//读取数据String getString(String key);Double getDouble(String key);boolean getBoolean(String key);float getFloat(String key);int getInt(String key);Object getObject(String key);long getLong(String key);
}

我们这里搞一个SP的实现类，实现上面我们写的接口

/**这个类的含义是通过SP的方式对数据进行读取
**/
public class SPIOHandler implements IOHandler {@Overridepublic void put(String key, String value) {//写数据，通过上面我们封装好的SPUtils工具类，相当于又加了一层封装//到时候我们直接调用SPIOHandler的put方法就行，其他都不用管了SPUtils.getInstance().putString(key, value).commit();}@Overridepublic void put(String key, int value) {}@Overridepublic void put(String key, long value) {}@Overridepublic void put(String key, boolean value) {}@Overridepublic void put(String key, Object value) {}@Overridepublic void put(String key, double value) {}@Overridepublic void put(String key, float value) {}@Overridepublic String getString(String key) {//获取数据也是一样return SPUtils.getInstance().getString(key, "");}@Overridepublic Double getDouble(String key) {return null;}@Overridepublic boolean getBoolean(String key) {return false;}@Overridepublic float getFloat(String key) {return 0;}@Overridepublic int getInt(String key) {return 0;}@Overridepublic Object getObject(String key) {return null;}@Overridepublic long getLong(String key) {return 0;}
}

这里我们模拟两种方式对数据的存取，一个是SP，一个是下面这个内存的形式。

/*** IOHandler的实现类，利用内存的方式对数据进行写入和读取*/
public class MemoryIOHandler implements IOHandler {//这里是一个缓存对象，可以对图片数据进行缓存，下次我们取图片的时候就不用再去请求网络了//可以直接从缓存拿LruCache<String, Object> mCache = new LruCache<>(10 * 1024 * 1024);@Overridepublic void put(String key, String value) {mCache.put(key, value);}@Overridepublic void put(String key, int value) {mCache.put(key, value);}@Overridepublic void put(String key, long value) {mCache.put(key, value);}@Overridepublic void put(String key, boolean value) {mCache.put(key, value);}@Overridepublic void put(String key, Object value) {mCache.put(key, value);}@Overridepublic void put(String key, double value) {mCache.put(key, value);}@Overridepublic void put(String key, float value) {mCache.put(key, value);}@Overridepublic String getString(String key) {return (String) mCache.get(key);}@Overridepublic Double getDouble(String key) {return (Double) mCache.get(key);}@Overridepublic boolean getBoolean(String key) {return (boolean) mCache.get(key);}@Overridepublic float getFloat(String key) {return 0;}@Overridepublic int getInt(String key) {return 0;}@Overridepublic Object getObject(String key) {return null;}@Overridepublic long getLong(String key) {return 0;}
}

在一开始我们是这样写入数据的。（写入数据举例，读取数据亦是如此）

SPUtils.getInstance().putString("username", "Colin").putString("userAge", "33").commit();

现在我们可以改成这样，通过我们封装的接口引用指向对应实现的子类对象

private IOHandler ioHandler;
ioHandler = new SPIOHandler();
ioHandler.put("username", "Colin");
ioHandler.put("userAge", "33");

我们这里切换也是非常方便的，前面说的我们获取数据也有可能用其他方法获取，比如上面说的内存方式，此时我们可以直接切换实现类即可。

ioHandler = new MemoryIOHandler();
ioHandler.put("username", "Colin");
ioHandler.put("userAge", "33");

这种写法：

优点：用不同的方式去写入读取数据都不需要关注它的具体实现，我们只需要切换对应的实现类就可以实现同样的逻辑。

缺点：在Activity上需要使用到这个类的时候都要手动去new对象。

引出简单工厂模式

从上面的代码可以看出，我们的UI界面每次都要在用到的地方new对象，对创建对象的依赖性太强，为了减少Activity对创建对象的依赖，我们定义一个工厂类，我们需要什么对象就传入对应的类型匹配即可。

/*** IOHandler工厂，帮助我们创建具体的实现了IOHandler的类*/
public class IOHandlerFactory {public enum IOType {PREFERENCES, MEMORY}//创建具体的IOHandler子类对象public static IOHandler createIOHandle(IOType ioType) {IOHandler ioHandler = null;switch (ioType) {case PREFERENCES:ioHandler = new SPIOHandler();break;case MEMORY:ioHandler = new MemoryIOHandler();break;}return ioHandler;}
}

来看下我们调用：

跟我们上面的其实大同小异，都是获取对应的对象，但是这里的优点是隐藏了对象的创建，解除了Activity和new实例的耦合，把创建对象的动作交给了我们定义好的工厂类，这就是简单工厂模式。

ioHandler = IOHandlerFactory.createIOHandle(IOHandlerFactory.IOType.PREFERENCES);
ioHandler.put("username", "Colin");
ioHandler.put("userAge", "33");

简单总结

优点：我们可以对创建的对象进行一些 “加工” ，而且调用方并不知道，因为工厂隐藏了这些细节，没有工厂的话，那我们就得自己在UI上写这些代码

缺点：每次增加子类或者删除子类对象的创建都需要打开这简单工厂类来进行修改，违反了我们的开闭原则，我们尽量不要修改已封装好的基类，简单来说就是不方便代码扩展，要修改的地方太多。

二.工厂方法模式

根据上面的前提我们优化一下代码，尽量保证面向接口编程。工厂方法模式是对简单工厂模式进一步的解耦，在工厂方法模式中是一个子类对应一个工厂类，而这些工厂类都实现于一个抽象接口IOFactory，这样就避免了简单工厂模式，代码都在一个工厂类里面，拆分成了一个个的工厂小类，用到哪个类就使用它对应的工厂类就行。

//定义工厂生产IOHandle需要遵守的规则
public interface IOFactory {IOHandler createIOHandler();
}

//SP的对象创建过程我们放到一个工厂类里面
public class SPIOFactory implements IOFactory {@Overridepublic IOHandler createIOHandler() {return new SPIOHandler();}
}
//内存方式的对象也是如此
public class MemoryIOFactory implements IOFactory {@Overridepublic IOHandler createIOHandler() {return new MemoryIOHandler();}
}

对比一下调用方式：

private IOHandler ioHandler;
/**这里我们通过实例化对应的SP工厂类，再通过工厂ioFactory对象调用createIOHandler返回的就是我们所需要的
IOHandler的子类的对象*/
IOFactory ioFactory = new SPIOFactory();
//IOFactory ioFactory = new MemoryIOFactory();当我们需要某个类的对象时候，直接替换它所对应的小工厂类即可ioHandler = ioFactory.createIOHandler();ioHandler.put("username", "Colin");ioHandler.put("userAge", "33");

优点：各个不同功能的实例对象的创建代码，也没有耦合在同一个工厂类里，而是抽象了一个工厂接口作为扩展点，这也是工厂方法模式对简单工厂模式解耦的一个体现。

缺点：工厂方法模式的缺点是每增加一个java类，就需要增加一个对应的工厂类，当我们的类很多的时候，那么对应的工厂类也会很多。

三.抽象工厂模式

基于工厂方法的进一步优化的方式。

public class IOHandlerFactory {//帮助我们创建对象通过传入的.class判断我们需要的类进而创建对应的对象public static <T extends IOHandler> IOHandler createIOHandle(Class<T> tClass) {IOHandler ioHandler = null;try {ioHandler = tClass.newInstance();} catch (IllegalAccessException e) {e.printStackTrace();} catch (InstantiationException e) {e.printStackTrace();}return ioHandler;}//这里举个SP例子public static IOHandler createSharePreferences() {return createIOHandle(SPIOHandler.class);}//...往下我们需要什么类的对象，就封装一个它对应的方法，外部直接调用即可。
}

调用：

private IOHandler ioHandler;ioHandler = IOHandlerFactory.createSharePreferences();ioHandler.put("username", "Colin");ioHandler.put("userAge", "33");

优点：相比于工厂方法模式不用一直创建新的对应的类的小工厂，扩展性更加，不会使代码越来越多，越复杂，把生产对象的过程抽象化，这样就可以和业务逻辑解耦，如果有新扩展，可以在IOHandlerFactory中增加对应的方法。

缺点：暂无。

Android源码中用到的工厂模式举例

一.BitmapFactory 源码工厂模式详解(简单工厂)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6eWBLcM3-1670077238626)(C:\Users\qiufh\Desktop\ff0aa6069cf62e419a2eaec1ad3e1a4.jpg)]

我们先看一下BitmapFactory 这个类里面具有的一些方法，快捷键ctrl+F12可查看当前类里面的方法，看到这我们就知道主要都是一些解码操作的方法，最后都是通过解析传入的图片的资源，最后转化成Bitmap对象。

接下来我们看一下BitmapFactory 生成 Bitmap的调用的过程吧，一开始我们调用的是这个方法传入资源的路径，然后往下走decodeFile(pathName, null);最后返回的是Bitmap，所以我们往下走bm = decodeStream(stream, null, opts);

public static Bitmap decodeFile(String pathName) {return decodeFile(pathName, null);
}public static Bitmap decodeFile(String pathName, Options opts) {validate(opts);Bitmap bm = null;InputStream stream = null;try {stream = new FileInputStream(pathName);bm = decodeStream(stream, null, opts);} catch (Exception e) {/*  do nothing.If the exception happened on open, bm will be null.*/Log.e("BitmapFactory", "Unable to decode stream: " + e);} finally {if (stream != null) {try {stream.close();} catch (IOException e) {// do nothing here}}}return bm;}

进到decodeStream(stream, null, opts);方法里面看看，

@Nullable
public static Bitmap decodeStream(@Nullable InputStream is, @Nullable Rect outPadding,@Nullable Options opts) {// we don't throw in this case, thus allowing the caller to only check// the cache, and not force the image to be decoded.if (is == null) {return null;}validate(opts);Bitmap bm = null;Trace.traceBegin(Trace.TRACE_TAG_GRAPHICS, "decodeBitmap");try {if (is instanceof AssetManager.AssetInputStream) {final long asset = ((AssetManager.AssetInputStream) is).getNativeAsset();bm = nativeDecodeAsset(asset, outPadding, opts, Options.nativeInBitmap(opts),Options.nativeColorSpace(opts));} else {bm = decodeStreamInternal(is, outPadding, opts);}if (bm == null && opts != null && opts.inBitmap != null) {throw new IllegalArgumentException("Problem decoding into existing bitmap");}setDensityFromOptions(bm, opts);} finally {Trace.traceEnd(Trace.TRACE_TAG_GRAPHICS);}return bm;
}

我们看看这行代码，很明显它的通过JNI调用了底层的方法来进行解码，这里我们暂时不深究，最后它是返回一个Bitmap对象，

bm = nativeDecodeAsset(asset, outPadding, opts, Options.nativeInBitmap(opts),Options.nativeColorSpace(opts));

生成Bitmap的大致的流程我们都过了一边，其实我们不必深究太多源码，我们调用者只需要知道我们传入图片的路径会返回一个Bitmap就行，而正是因为它使用了工厂模式，把这些细节都屏蔽了，所以我们不用操心，甭管它生成的，我给你一个图片路径你给我生成一个 Bitmap 就好了。

说到这里，可能大家还不明白这玩玩意儿哪里体现工厂模式了，不慌，接下来继续分析。BitmapFactory,通过传入不同的条件，得到同样的bitmap，回顾我们上面说的简单工厂模式，是不是传入我们想要的type类型就可以从工厂里面生产出我们想要的实例对象，这是不是很类似呢。看下面的代码，最终都是为的是生成Bitmap对象但是我们可以传入不同的条件参数进行获取，我们都可以理解为在同一个工厂用不同的条件去生产相同的产品。

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例

但是这样的简单工厂模式缺点很明显，比如我们有另外一种生产Bitmap的方法出现的时候，我们就要去修改工厂类BitmapFactory，违反了开闭原则，我们尽量不要去修改我们的基类。

/*** Creates Bitmap objects from various sources, including files, streams,* and byte-arrays.*/
public class BitmapFactory {public static Bitmap decodeFile(String pathName, Options opts){......}public static Bitmap decodeFile(String pathName) {......}public static Bitmap decodeResourceStream(Resources res, TypedValue value,InputStream is, Rect pad, Options opts) {......}public static Bitmap decodeResource(Resources res, int id, Options opts) {......}public static Bitmap decodeResource(Resources res, int id) {......}public static Bitmap decodeByteArray(byte[] data, int offset, int length, Options opts){......}public static Bitmap decodeByteArray(byte[] data, int offset, int length) {......}public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) {......}public static Bitmap decodeStream(InputStream is) {......}public static Bitmap decodeFileDescriptor(FileDescriptor fd, Rect outPadding, Options opts) {......}public static Bitmap decodeFileDescriptor(FileDescriptor fd) {......}
}

二.Retrofit的工厂模式(抽象工厂)

由于Retrofit涉及的源码比较庞大，在这里仅仅举例介绍这个框架里面所应用到的工厂模式吗，下面是Retrofit的简单使用方式，我们简单分析一下GsonConverterFactory.create()和RxJavaCallAdapterFactory.create()，很明显从名字上就可以看出是工厂模式。两者创建的形式都是抽象工厂模式，大同小异，拿GsonConverterFactory.create()举例说明，请看下文。

new Retrofit.Builder().baseUrl("https://www.baidu.com/").client(new OkHttpClient()).addConverterFactory(GsonConverterFactory.create()).addCallAdapterFactory(RxJavaCallAdapterFactory.create()).build();

我们点击create()方法来到源码中，

public final class GsonConverterFactory extends Converter.Factory {public static GsonConverterFactory create() {return create(new Gson());}

点击这里进入到抽象工厂中看看，

Converter.Factory

可以看到Factory是abstract修饰，那么就可以明确它是使用的是抽象工厂。

//这是个数据的转换器的抽象类，泛型F表示输入的参数，T是输出的参数，也就是我们转换完成之后的数据类型。
public interface Converter<F, T> {//这是一个接口里面的方法，主要做的是转换的操作@Nullable T convert(F value) throws IOException;abstract class Factory {//请求响应public @Nullable Converter<ResponseBody, ?> responseBodyConverter(Type type,Annotation[] annotations, Retrofit retrofit) {return null;}//发起请求public @Nullable Converter<?, RequestBody> requestBodyConverter(Type type,Annotation[] parameterAnnotations, Annotation[] methodAnnotations, Retrofit retrofit) {return null;}//该工厂用于转换字符串类型的转换器，public @Nullable Converter<?, String> stringConverter(Type type, Annotation[] annotations,Retrofit retrofit) {return null;}protected static Type getParameterUpperBound(int index, ParameterizedType type) {return Utils.getParameterUpperBound(index, type);}protected static Class<?> getRawType(Type type) {return Utils.getRawType(type);}}
}

接下来我们看看它的具体实现类，通过封装一个 create 方法，来创建工厂对象，外部调用者就不需要关系工厂对象是如何创建的。再一个通过responseBodyConverter、requestBodyConverter 方法分别创建了请求响应和请求发起这两种产品的对象。

//这里就是创建了它的工厂对象
public static GsonConverterFactory create() {return create(new Gson());
}
//这里是通过封装了一个create方法传入一个Gson对象创建的工厂
public static GsonConverterFactory create(Gson gson) {if (gson == null) throw new NullPointerException("gson == null");return new GsonConverterFactory(gson);}@Overridepublic Converter<ResponseBody, ?> responseBodyConverter(Type type, Annotation[] annotations,Retrofit retrofit) {TypeAdapter<?> adapter = gson.getAdapter(TypeToken.get(type));return new GsonResponseBodyConverter<>(gson, adapter);}@Overridepublic Converter<?, RequestBody> requestBodyConverter(Type type,Annotation[] parameterAnnotations, Annotation[] methodAnnotations, Retrofit retrofit) {TypeAdapter<?> adapter = gson.getAdapter(TypeToken.get(type));return new GsonRequestBodyConverter<>(gson, adapter);}

总结：工厂模式属于创建型的设计模式，主要设计的核心在创建我们的对象上面，使得创建对象和第三方调用者相隔离，这样对象的提供方和调用方的耦合关系就会减小。