安卓开发用到的设计模式（1）创建型模式

文章目录

安卓开发用到的设计模式（1）创建型模式
- 1. 单例模式（Singleton Pattern）
- 2. 工厂模式（Factory Pattern）
- 3. 抽象工厂模式（Abstract Factory Pattern）
- 4. 建造者模式（Builder Pattern）
- 5. 原型模式（Prototype Pattern）

本文首发地址 https://h89.cn/archives/397.html

1. 单例模式（Singleton Pattern）

单例模式确保一个类只有一个实例，并提供一个全局访问点。

在Android中的主要应用场景：

系统服务 (System Services)
- SystemService的获取: Android系统中的各种服务（如 LayoutInflater, WindowManager, ActivityManager 等）都是通过 Context.getSystemService() 方法获取的单例实例。这样做可以确保系统中只有一个服务实例在运行，节省资源并保证状态一致性。
- 确保系统服务的唯一性: 例如，LocationManager 负责管理设备的位置信息，如果允许创建多个实例，可能会导致位置更新冲突或资源浪费。通过单例模式，系统确保所有组件都使用同一个 LocationManager 实例。
数据管理器 (Data Managers)
- SharedPreferences管理器: 在应用中管理用户偏好设置时，通常会使用 SharedPreferences。为了避免频繁创建和销毁 SharedPreferences 实例，以及确保所有地方访问的是同一份配置数据，可以将其封装成一个单例管理器。
- 数据库连接管理: 数据库连接是昂贵的资源。在Android应用中，为了高效地管理数据库访问，通常会将 SQLiteOpenHelper 或 Room Database 的实例设计成单例，确保应用生命周期内只有一个数据库连接池或数据库实例，从而优化性能和资源使用。

2. 工厂模式（Factory Pattern）

工厂模式提供了一种创建对象的最佳方式，在创建对象时不会对客户端暴露创建逻辑。

在Android中的主要应用场景：

Fragment创建 (Fragment Creation)
- FragmentFactory: 在现代Android开发中，FragmentFactory 提供了一种机制来控制 Fragment 的实例化过程。通过自定义 FragmentFactory，可以在创建 Fragment 时注入依赖，或者根据特定条件创建不同的 Fragment 子类，而无需在调用方暴露具体的创建逻辑。
- 统一管理Fragment的实例化: 当 Fragment 的创建过程变得复杂（例如需要传递特定的参数或依赖）时，使用工厂模式可以将创建逻辑集中管理，使得调用方只需通过工厂接口请求 Fragment 实例，而不需要关心其内部创建细节。
Intent服务 (Intent Services)
- IntentService的创建: IntentService 是 Android 中用于处理异步任务的服务基类。虽然 IntentService 本身不是一个典型的工厂模式应用，但其启动方式 (startService(Intent)) 可以看作是一种简化的工厂方法调用，系统根据传入的 Intent 来创建并启动相应的服务实例，处理后台任务。

3. 抽象工厂模式（Abstract Factory Pattern）

抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

在Android中的主要应用场景：

主题系统 (Theme System)
- 不同主题风格的UI组件创建: 抽象工厂模式非常适合用于实现 Android 的主题系统。例如，可以定义一个抽象工厂接口 UIComponentFactory，包含创建按钮、文本框等 UI 组件的方法。然后为不同的主题（如 LightTheme, DarkTheme）实现具体的工厂类，每个工厂类负责创建符合该主题风格的 UI 组件实例。这样，切换主题时只需切换使用的工厂实例，即可创建一套风格一致的 UI 组件族。
- 确保UI组件风格的一致性: 通过抽象工厂，可以确保在同一主题下创建的所有 UI 组件都遵循该主题的设计规范，避免风格混杂。
- 例如：Material Design中的Light/Dark主题组件族: Android 的 Material Design 主题系统就是抽象工厂模式的一个典型应用。开发者通过应用不同的主题，系统会使用对应的主题工厂来创建具有特定颜色、字体、形状等属性的 UI 元素。
数据访问层 (Data Access Layer)
- 不同数据源的访问对象创建: 在一个应用中，数据可能来源于多种渠道，如本地数据库、网络 API、文件存储或内存缓存。可以定义一个抽象工厂 DataAccessFactory，包含 createDatabaseAccessor(), createNetworkAccessor(), createCacheAccessor() 等方法。然后为不同的数据源实现具体的工厂类（如 LocalDataFactory, RemoteDataFactory）。应用层通过抽象工厂接口获取数据访问对象，无需关心底层数据源的具体实现。
- 统一管理数据访问接口: 抽象工厂模式提供了一个统一的接口来创建不同数据源的访问对象，使得数据访问逻辑更加模块化和易于管理。
- 例如：本地存储、网络API、缓存等数据源的访问对象: 开发者可以根据当前环境或配置，使用不同的工厂来获取操作 SQLite 数据库、Retrofit 网络请求或 Room 数据库的访问对象。
多平台适配 (Multi-platform Adaptation)
- 创建不同平台特定的组件: 虽然 Android 主要运行在移动设备上，但在处理不同 Android 版本或特定设备特性时，抽象工厂模式可以派上用场。例如，某些功能在不同 Android 版本上有不同的实现方式。可以定义一个抽象工厂 FeatureFactory，然后为不同的 Android 版本（如 Android 10, Android 11）实现具体的工厂类，每个工厂类创建符合该版本特性的功能组件。
- 处理平台差异化实现: 通过抽象工厂，可以将平台相关的实现细节封装起来，使得应用的核心逻辑与平台差异性解耦。
- 例如：不同Android版本的特性适配: 比如，某些权限管理或后台任务执行方式在不同 Android 版本之间有较大差异，可以使用抽象工厂来提供不同版本的适配器或实现类。

4. 建造者模式（Builder Pattern）

建造者模式是将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建不同的表示。

在Android中的主要应用场景：

Dialog的构建 (Dialog Construction)
- AlertDialog.Builder: 这是 Android 中建造者模式最经典的例子之一。创建一个复杂的 AlertDialog 需要设置标题、消息、按钮、列表项等多个属性。AlertDialog.Builder 提供了一系列链式调用的方法（如 .setTitle(), .setMessage(), .setPositiveButton()），允许开发者逐步设置对话框的各个部分，最后通过 .create() 或 .show() 方法构建并显示对话框。这种方式使得对话框的构建过程清晰且灵活，避免了构造函数参数过多的问题。
- 通过链式调用设置对话框的各个属性: 链式调用是建造者模式在代码实现上的常见表现形式，它使得构建过程读起来像一系列指令。
Retrofit的配置 (Retrofit Configuration)
- OkHttpClient.Builder: 在使用 Retrofit 进行网络请求时，通常需要配置底层的 OkHttpClient。OkHttpClient.Builder 提供了丰富的配置选项，如设置超时时间、添加拦截器、配置缓存等。开发者可以通过 OkHttpClient.Builder 的链式调用方法来逐步构建符合需求的 OkHttpClient 实例，然后将其用于创建 Retrofit 实例。这同样体现了建造者模式在构建复杂对象时的优势。
- 配置网络请求的各种参数: 通过 Builder 模式，可以将 OkHttpClient 的各种配置参数（如连接池、安全设置、事件监听器等）清晰地分离和组织起来。

5. 原型模式（Prototype Pattern）

原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

在Android中的主要应用场景：

Intent的克隆 (Intent Cloning)
- Intent对象的复制: 在 Android 中，Intent 对象实现了 Parcelable 接口，可以通过序列化和反序列化来实现“克隆”。虽然不是严格意义上的原型模式（原型模式通常指通过 clone() 方法复制自身），但在概念上，通过复制一个现有的 Intent 实例来创建新的 Intent，并在此基础上进行修改（如添加或修改 Extra 数据），以启动不同的组件或传递不同的信息，这与原型模式通过复制原型创建新对象的思想是相符的。
- 保持原有Intent的数据: 复制 Intent 可以保留其原有的动作、类别、数据 URI、Flags 以及 Extra 数据，方便在相似的场景下复用大部分配置。
配置对象的复制 (Configuration Object Copying)
- 复制已有的配置信息: 在 Android 开发中，有时需要基于一个已有的配置对象（如网络请求配置、UI 样式配置等）创建新的配置对象，并在新对象上进行少量修改。如果配置对象比较复杂，包含多个字段，手动复制会很繁琐且容易出错。如果配置对象支持深拷贝或提供了复制方法，就可以利用原型模式的思想，快速创建一个与原型对象相同的新对象，然后在新的对象上进行修改，而不会影响到原型对象。
- 在原有配置基础上修改: 这种模式特别适用于需要创建多个相似对象，但每个对象又有一些细微差别的场景，通过复制和修改比从头创建更加高效和便捷。