面试题：Flutter中StatefulWidget在复杂业务场景下的状态管理策略

Question

假设有一个电商应用，商品列表页面使用StatefulWidget构建。该页面包含商品筛选、排序、分页加载等功能，并且在切换筛选条件和排序方式时需要保留当前分页位置及已加载的数据状态。请详细描述你会采用哪些StatefulWidget状态管理方法和设计模式来高效实现这些功能，并说明原因。

Answer 1

状态管理方法

1. 单状态管理（Single State Management）：在 StatefulWidget 内部管理状态。如果商品筛选、排序、分页等状态之间耦合度较低，且逻辑相对简单，这种方式可以直接在 _MyWidgetState 类中定义状态变量，如 List<Product> products 存储已加载商品数据，int currentPage 记录当前分页位置，FilterCondition filter 记录筛选条件，SortOrder sort 记录排序方式。在相应的方法（如筛选按钮点击、排序按钮点击、分页加载等方法）中更新这些状态变量，触发 setState 方法更新UI。原因是实现简单，适用于功能逻辑不太复杂的场景，对小型应用或局部功能模块较为适用。
2. InheritedWidget：当商品列表页面及其子部件都需要访问和更新相同的状态数据时，InheritedWidget 比较合适。创建一个继承自 InheritedWidget 的类，如 ProductListStateProvider，在其中存储商品筛选、排序、分页等状态数据。子部件通过 of 方法获取该状态数据。这样，当状态变化时，依赖该状态的子部件会自动重建。例如，商品列表子部件和分页按钮子部件都可以通过 ProductListStateProvider.of(context) 获取状态。原因是它提供了一种高效的方式在 widget 树中共享状态，减少了状态传递的层级，使得状态管理更具层次性和可读性。
3. Provider：它是 Flutter 社区常用的状态管理库，基于 InheritedWidget 实现。可以创建不同的 ChangeNotifier 类分别管理筛选、排序、分页等状态，如 FilterNotifier、SortNotifier、PaginationNotifier。通过 Provider 将这些 ChangeNotifier 提供给 widget 树，使用 Consumer 或 context.watch 来监听状态变化并更新UI。例如，在商品筛选按钮点击时，更新 FilterNotifier 的状态，与之相关的UI（如商品列表展示）会自动更新。原因是它分离了业务逻辑和UI，使得代码结构更清晰，易于维护和测试，适用于中等规模及以上的应用，并且支持依赖注入，方便进行单元测试。
4. Bloc（Business Logic Component）：将商品筛选、排序、分页加载等业务逻辑封装在不同的 Bloc 中，如 FilterBloc、SortBloc、PaginationBloc。每个 Bloc 通过 Stream 发出状态变化，UI 通过 BlocBuilder 或 BlocListener 来监听状态变化并更新UI。例如，在 FilterBloc 接收到筛选条件改变的事件时，处理业务逻辑并发出新的筛选状态，UI根据新状态更新商品列表。原因是它将业务逻辑与UI完全分离，使得代码可测试性更强，适合大型复杂应用，特别是业务逻辑复杂且变化频繁的场景。

设计模式

1. 观察者模式（Observer Pattern）：结合上述状态管理方法，特别是在使用 ChangeNotifier（如 Provider 库）或 Bloc 时，体现了观察者模式。状态（被观察对象）发生变化时，相关的UI部件（观察者）会收到通知并更新。例如，当商品筛选条件改变（FilterNotifier 状态变化），商品列表UI（观察者）会根据新的筛选结果更新展示，这种模式解耦了状态和UI，使得代码更具可维护性和扩展性。
2. 策略模式（Strategy Pattern）：在商品排序功能中，可采用策略模式。定义一个排序策略接口，如 SortStrategy，不同的排序方式（如按价格升序、按销量降序等）实现该接口。在排序逻辑处理中，根据用户选择的排序方式，使用相应的策略对象进行排序。这样，当需要添加新的排序方式时，只需要实现新的 SortStrategy 接口实现类，而不需要修改大量现有代码，提高了代码的可维护性和扩展性。
3. 工厂模式（Factory Pattern）：在分页加载数据时，可以使用工厂模式。定义一个工厂类，如 ProductPageFactory，根据当前分页位置和筛选、排序条件生成对应的商品数据请求。这样可以将数据请求逻辑封装在工厂类中，方便管理和维护，并且在需要修改数据请求逻辑（如更换API接口）时，只需要在工厂类中修改，而不影响其他部分的代码。