（十三）ArkTS 开发中的设计模式应用 原创

ArkTS 开发中的设计模式应用

设计模式基础

设计模式的分类与作用

设计模式是软件开发中针对反复出现问题总结归纳出的通用解决方案。它如同建筑蓝图，指导开发者构建更具可维护性、可扩展性和可复用性的软件系统。根据目的和用途，设计模式主要分为创建型、结构型和行为型三类。创建型模式专注于对象创建过程的控制，如单例模式确保类仅有一个实例；结构型模式关注如何将类或对象组合成更大的结构，像代理模式为其他对象提供代理以控制对它的访问；行为型模式则着重处理对象间的交互和职责分配，观察者模式就是典型，它定义对象间的一种一对多依赖关系，当一个对象状态改变时，所有依赖它的对象都会得到通知并自动更新。

设计模式的原则

遵循设计模式原则是有效运用设计模式的关键。单一职责原则要求一个类只负责一项职责，这样类的功能更聚焦，维护和修改时不会影响其他功能。开闭原则强调软件实体（类、模块、函数等）应该对扩展开放，对修改关闭，即通过扩展代码来满足新需求，而非修改现有代码。里氏替换原则规定子类对象能够替换其父类对象，且程序逻辑不受影响，保证了继承体系的稳定性。接口隔离原则倡导使用多个专门的接口，而非一个庞大的总接口，让客户端仅依赖它需要的接口，降低耦合度。依赖倒置原则主张高层模块不应该依赖低层模块，二者都应该依赖抽象，抽象不应该依赖细节，细节应该依赖抽象，提升系统的灵活性和可维护性。

常见设计模式在 ArkTS 中的应用

单例模式

在 ArkTS 中，单例模式常用于确保一个类仅有一个实例，并提供全局访问点。例如，在应用程序中管理全局状态的类，若多次实例化可能导致数据不一致，使用单例模式就能避免这种情况。实现时，可通过在类内部维护一个静态变量来存储唯一实例，将构造函数设置为私有，防止外部直接实例化。提供一个静态方法用于获取该实例，若实例不存在则创建，已存在则直接返回。

​​class GlobalState {​​

​​private static instance: GlobalState;​​

​​private state: any;​​

​​private constructor() {​​

​​this.state = {};​​

​​}​​

​​public static getInstance(): GlobalState {​​

​​if (!GlobalState.instance) {​​

​​GlobalState.instance = new GlobalState();​​

​​}​​

​​return GlobalState.instance;​​

​​}​​

​​public getState() {​​

​​return this.state;​​

​​}​​

​​public setState(newState: any) {​​

​​this.state = newState;​​

​​}​​

​​}​​

观察者模式

观察者模式在 ArkTS 中可用于实现组件间的解耦通信。比如在一个界面中，多个组件依赖于某个数据的变化，当数据更新时，这些组件能自动响应。可以定义一个主题类，维护观察者列表，当主题状态改变时，遍历列表通知所有观察者。观察者则实现一个更新方法，接收主题传递的状态信息并进行相应处理。

​​// 主题类​​

​​class DataSource {​​

​​private observers: Array<Observer> = [];​​

​​private data: any;​​

​​public attach(observer: Observer) {​​

​​this.observers.push(observer);​​

​​}​​

​​public detach(observer: Observer) {​​

​​this.observers = this.observers.filter((obs) => obs!== observer);​​

​​}​​

​​public notify() {​​

​​this.observers.forEach((observer) => observer.update(this.data));​​

​​}​​

​​public setData(newData: any) {​​

​​this.data = newData;​​

​​this.notify();​​

​​}​​

​​}​​

​​// 观察者接口​​

​​interface Observer {​​

​​update(data: any): void;​​

​​}​​

​​// 具体观察者类​​

​​class ComponentA implements Observer {​​

​​public update(data: any) {​​

​​console.log('ComponentA updated with data:', data);​​

​​// 执行组件A的更新逻辑​​

​​}​​

​​}​​

设计模式的优缺点分析

模式的适用场景

单例模式适用于需要全局唯一控制的场景，如日志记录器、数据库连接池等，能避免资源浪费和数据不一致问题。观察者模式在需要实现事件驱动、组件间松耦合通信的场景中表现出色，像图形用户界面中用户操作引发多个组件联动更新的情况。

模式的潜在问题

单例模式可能导致代码的可测试性变差，因为单例的全局唯一性使得在测试时难以模拟不同状态。同时，若单例类的生命周期过长，可能会占用过多资源。观察者模式中，若观察者数量过多，主题通知所有观察者的过程可能会带来性能开销，且观察者与主题间的依赖关系可能变得复杂难以维护，出现循环依赖等问题。

设计模式的实际案例解读

以一个简单的音乐播放器应用为例，假设需要实现播放列表管理和播放状态监控功能。在播放列表管理中，可使用单例模式创建一个播放列表类，确保整个应用中只有一个播放列表实例，方便统一管理歌曲添加、删除等操作。对于播放状态监控，如播放、暂停、停止等状态变化时通知界面上的播放按钮、进度条等组件更新显示，可采用观察者模式。播放状态作为主题，各相关组件作为观察者，当播放状态改变时，及时通知观察者进行相应更新，实现界面与播放逻辑的解耦，提升代码的可维护性和扩展性。通过这些设计模式的应用，音乐播放器应用的结构更加清晰，功能实现更加高效稳定。