是否可以将多态性与抽象层一起用于颤动中的不同小部件

Question

我有一组大约8个小部件，这些小部件都接受X型的单个参数，并以不同的方式显示X类型的内容。我试图创建的是一个抽象层，它定义了这种小部件的结构。除结构外，抽象层还将定义一种工厂方法来确定基于ID的实现。不同的实现是所有扩展无状态或状态Fulwidget的小部件。

抽象层看起来如下：

abstract class AbstractWidget {
final X content;
factory AbstractWidget({@required int id, @required X content}) {
  switch (id) {
    case 1:
      return Implementation1(content);
      break;
    default: return Implementation2(content);
   }
  }
 }

实现看起来如下：

class Implementation1 extends StatelessWidget implements AbstractWidget {
  final X content;
  Implementation1(this.content);
  @override
  Widget build(BuildContext context) {
    // Display content in some type of way
  }
}

所以我要实现的目标是：

var widgetList = new List<Widget>();
for (var item in items) {
  X content = fetchContentFromAPI();
  widgetList.add(AbstractWidget(content: content, id: item.id));
}
return Column(children: widgetList);

这是行不通的，因为从技术上讲，AbstractWidget只能返回无状态或StateFulwidgets的实例，即使它不是一种小部件类型。如果有人知道一种更好的实施我的结构的方法，那将对我有很大帮助！

Answer 1

使您的AbstractWidget扩展或实现Widget。但是，我必须同意RémiRousselet。一个抽象的班级不应该了解其孩子的任何知识(这就是为什么它是抽象的原因(。我会做：

class Foo extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    var widgetList = new List<Widget>();
    for (var item in items) {
      X content = fetchContentFromAPI();
      widgetList.add(abstractWidgetWith(content: content, id: item.id));
    }
    return Column(children: widgetList);
  }
  Widget abstractWidgetWith({@required int id, @required X content}) {
    switch (id) {
      case 1:
        return Implementation1(content);
      default:
        return Implementation2(content);
    }
  }
}
abstract class AbstractWidget {
  final X content;
  AbstractWidget(this.content);
}
class Implementation1 extends StatelessWidget implements AbstractWidget {
  final X content;
  Implementation1(this.content);
  @override
  Widget build(BuildContext context) {
    // Display content in some type of way
  }
}
class Implementation2 extends StatelessWidget implements AbstractWidget {
  final X content;
  Implementation2(this.content);
  @override
  Widget build(BuildContext context) {
    // Display content in some type of way
  }
}

我只想对您说的话进行补充：

只是广泛的开关案例违反了我所教的设计模式和原则。

这里的想法是始终寻找抽象，而不是重复条件结构。注意重复强调。如果条件结构不止一次使用，则抽象主要是一个更好的选择。如果不是这种情况，您可能会通过创建抽象来解决问题。

再次，注意重复强调。当您拥有大量的状态结构时，您倾向于需要抽象，但是最后我最终会使用一个条件。换句话说，您无法摆脱状况结构，您只会少使用它。

在这个问题的背景下，您似乎遵循了所有规则。对我来说，这看起来像是一个干净的代码。