首页 > 解决方案 > 扩展一个小部件真的是一种反模式吗?

问题描述

我在几个地方读到扩展 Flutter 小部件是一种反模式。真的吗?

我使用小部件子类化来减少嵌套,方法是对要删除的小部件进行子类化并将其小部件放入其构造函数中,就像这样

class Foo extends FormBuilder {
    Foo() : super (
        // bunch of widgets here
    );
}

扩展无状态小部件似乎更受欢迎,但它向树中添加了几行代码和一个小部件,这不是我的偏好:

class Foo extends StatelessWidget {
    @override
    Widget build(BuildContext context) {
    return FormBuilder(
       // bunch of widgets here
    );
}

我读过从函数返回小部件是一种反模式,因为它破坏了渲染优化。我的第一种方法是否同样有隐藏的副作用?即,它真的是反模式吗?

标签: fluttersubclassanti-patterns

解决方案


扩展有状态小部件可能会导致问题,因为它们的状态是输入到超类中的,并且您不能扩展它们的状态,因为大多数状态类都是私有的。许多查找方法BuildContext.findAncestorStateOfType()都可能会失败。

扩展无状态小部件在大多数情况下应该可以工作,但不推荐,正如您已经发现的那样。

一般来说,对于 Flutter 的整个响应式和小部件性质,组合优于继承的原则是一个很好的模式。

您将小部件组合成新小部件、新小部件、新小部件、新小部件……您明白了。

除此之外,您节省了 2 行代码,这些代码大部分是自动生成的,但是您剥夺了 VSCode/IntelliJ 中所有简单的帮助程序,例如“使用填充包裹小部件”。FormBuilder在您的应用程序中使用填充来包装扩展内容要困难得多。如果你编写它很简单,只需将它包裹在Foo. 您用于主题、颜色、字体样式等的所有其他小部件也是如此 - 填充只是一个示例。


推荐阅读