17370845950

本文探讨了在Java中如何优雅地组织和重用具有相似初始化逻辑的代码，特别是在处理不同类型但结构一致的绑定对象时。针对直接在抽象基类构造器中调用抽象方法可能导致的潜在问题，文章提出了一种基于函数式接口和方法引用的安全有效解决方案，通过将具体的创建逻辑作为参数传递，实现了初始化代码的解耦与复用，同时确保了面向对象设计的健壮性。

引言：统一初始化逻辑的必要性

在java应用开发中，我们经常会遇到多个类具有相似的属性和初始化步骤，但具体类型或某些细节有所不同的场景。例如，在一个android应用中，可能有多种ui元素（如 loadelement 和 errorelement），它们都需要初始化一个 viewdatabinding 对象，并设置其生命周期所有者（lifecycleowner）。尽管具体的 binding 类型不同（loadingelementbinding vs errorelementbinding），但初始化流程中的大部分逻辑是共享的。

考虑以下初始代码结构，其中 LoadElement 和 ErrorElement 各自维护并初始化自己的 binding：

public class LoadElement {
    LoadingElementBinding binding;

    public LoadElement(ViewGroup parent) {
        binding = LoadingElementBinding.inflate(
                       LayoutInflater.from(parent.getContext()),
                       parent,
                       false);
        binding.setLifecycleOwner(ViewTreeLifecycleOwner.get(parent));
    }

    public void doSomething() {
        // 与 binding 相关的业务逻辑
    }
}

public class ErrorElement {
    ErrorElementBinding binding;

    public ErrorElement(ViewGroup parent) {
        binding = ErrorElementBinding.inflate(
                       LayoutInflater.from(parent.getContext()),
                       parent,
                       false);
        binding.setLifecycleOwner(ViewTreeLifecycleOwner.get(parent));
    }

    public void doSomething() {
        // 与 binding 相关的业务逻辑
    }
}

这种模式导致了代码重复，难以维护。理想情况下，我们希望能够将这些通用的初始化代码进行抽象和复用。

面临的挑战：构造器中调用抽象方法的陷阱

一种直观的解决方案是引入一个抽象基类 BindingElement，并在其中定义一个抽象方法来创建特定类型的 binding，然后在基类的构造器中调用这个抽象方法。

public abstract class BindingElement {
    T binding;

    public BindingElement (ViewGroup parent) {
        // 尝试在构造器中调用抽象方法
        binding = createBinding(LayoutInflater.from(parent.getContext()), parent);
        binding.setLifecycleOwner(ViewTreeLifecycleOwner.get(parent));
    }

    // 抽象方法，由子类实现具体的 binding 创建逻辑
    abstract T createBinding(LayoutInflater inflater, ViewGroup parent);

    public void doSomething() {
        // 共享的业务逻辑
    }
}

public class LoadElement extends BindingElement{
    public LoadElement(ViewGroup parent) {
        super(parent);
    }

    @Override
    LoadingElementBinding createBinding(LayoutInflater inflater, ViewGroup parent){
       return LoadingElementBinding.inflate(inflater, parent, false);
    }
}
// ... 其他子类类似

然而，这种做法在Java中存在潜在的风险。在Java中，当一个对象的构造器被调用时，其父类的构造器会首先执行。如果在父类构造器中调用了一个非 final 或 private 的方法（尤其是抽象方法），并且该方法在子类中被重写，那么在子类完全初始化之前，子类重写的方法可能会被调用。这可能导致访问到尚未初始化完成的子类成员变量，从而引发 NullPointerException 或其他不可预测的行为。这种设计模式通常被认为是“构造器中调用虚方法”的反模式。

解决方案：利用函数式接口与方法引用

为了安全且优雅地解决上述问题，我们可以利用Java 8引入的函数式接口（FunctionalInterface）和方法引用（Method Reference）。核心思想是将具体的 binding 创建逻辑封装在一个函数式接口中，并通过构造器参数将其传递给抽象基类。这样，基类在构造时接收的是一个已准备好的“创建器”，而不是主动调用一个尚未完全确定的抽象方法。

实现步骤与代码示例

1. 定义函数式接口 BindingCreator

首先，我们定义一个函数式接口 BindingCreator，它包含一个抽象方法，用于创建特定类型的 ViewDataBinding 实例。

@FunctionalInterface
public interface BindingCreator{
    /**
     * 创建一个 ViewDataBinding 实例。
     * @param inflator 用于布局膨胀的 LayoutInflater
     * @param parent 父视图组
     * @param attachToParent 是否将布局附加到父视图组
     * @return 创建的 ViewDataBinding 实例
     */
    T createBinding(LayoutInflater inflator, ViewGroup parent, boolean attachToParent);
}

这个接口的签名与 ViewDataBinding 的静态 inflate 方法兼容。

2. 重构抽象基类 BindingElement

修改 BindingElement 抽象类的构造器，使其接受一个 BindingCreator 实例作为参数。在构造器内部，通过这个 BindingCreator 实例来执行 binding 的创建逻辑。

import android.view.LayoutInflater;
import android.view.ViewGroup;
import androidx.lifecycle.ViewTreeLifecycleOwner;
import androidx.databinding.ViewDataBinding;

public abstract class BindingElement {
    protected T binding; // 建议设为 protected 以便子类访问

    /**
     * 构造函数，通过 BindingCreator 接收具体的 binding 创建逻辑。
     * @param parent 父视图组
     * @param bindingCreator 用于创建 ViewDataBinding 实例的函数式接口
     */
    public BindingElement(ViewGroup parent, BindingCreator bindingCreator){
        // 使用传入的 bindingCreator 来创建 binding 实例
        binding = bindingCreator.createBinding(
                       LayoutInflater.from(parent.getContext()),
                       parent,
                       false); // 假设 false 是一个通用参数，或可由子类传递
        binding.setLifecycleOwner(ViewTreeLifecycleOwner.get(parent));
    }

    public void doSomething() {
        // 共享的业务逻辑，可操作 binding
    }

    // 允许子类或外部访问 binding
    public T getBinding() {
        return binding;
    }
}

3. 实现具体子类 LoadElement 和 ErrorElement

现在，具体的子类 LoadElement 和 ErrorElement 只需要在其构造器中调用 super()，并传入对应 Binding 类的静态 inflate 方法的方法引用即可。

import android.view.ViewGroup;
import com.example.app.LoadingElementBinding; // 假设这是你的 binding 类
import com.example.app.ErrorElementBinding;   // 假设这是你的 binding 类

public class LoadElement extends BindingElement{
    public LoadElement(ViewGroup parent) {
        // 通过方法引用将 LoadingElementBinding::inflate 作为 BindingCreator 传入
        super(parent, LoadingElementBinding::inflate);
    }
    // ... 可以有 LoadElement 特有的方法
}

public class ErrorElement extends BindingElement{
    public ErrorElement(ViewGroup parent) {
        // 通过方法引用将 ErrorElementBinding::inflate 作为 BindingCreator 传入
        super(parent, ErrorElementBinding::inflate);
    }
    // ... 可以有 ErrorElement 特有的方法
}

工作原理详解

1. @FunctionalInterface: BindingCreator 被标记为函数式接口，这意味着它只包含一个抽象方法 createBinding。这使得它可以用作 lambda 表达式或方法引用的目标类型。
2. 方法引用 LoadingElementBinding::inflate: 当我们将 LoadingElementBinding::inflate 作为参数传递给 super() 构造器时，Java 编译器会自动将其转换为一个实现了 BindingCreator 接口的匿名类实例。这个匿名类的 createBinding 方法体内部会调用 LoadingElementBinding.inflate 静态方法，并传入相应的参数。
3. 参数传递与解耦: 这种方式将具体的 binding 创建逻辑从基类的内部抽象方法调用，转变为子类通过构造器参数“推送”给基类。基类不再需要知道如何创建具体的 binding，它只知道如何使用一个 BindingCreator 来完成创建任务。这有效地解耦了基类与子类的具体实现细节，同时避免了在基类构造器中调用未完全初始化的子类方法的风险。

优点与注意事项

优点：

• 安全性提升: 彻底避免了在基类构造器中调用抽象方法所带来的潜在风险，保证了对象构造过程的健壮性。
• 代码复用与简洁: 将通用的初始化步骤（如设置 LifecycleOwner）集中在基类中，减少了重复代码。方法引用使得代码更加简洁、易读。
• 高度解耦: 基类 BindingElement 不再依赖于具体的 Binding 实现细节，而是通过接口与具体创建逻辑交互，提高了代码的灵活性和可维护性。
• 符合OOP原则: 这种设计遵循了开闭原则（对扩展开放，对修改关闭），新的 Binding 类型可以很容易地通过创建新的子类和传入对应的方法引用来集成。

注意事项：

• 方法签名匹配: 确保函数式接口的抽象方法签名与所引用的静态方法（如 inflate）的签名完全兼容，包括参数类型、顺序和返回类型。
• 复杂逻辑: 对于更复杂的 binding 初始化逻辑，如果仅仅通过一个方法引用不足以表达，可能需要调整 BindingCreator 的方法签名，或者考虑引入更复杂的工厂模式（但通常函数式接口足以应对大多数情况）。
• 参数传递: 如果 bindingCreator.createBinding 需要的参数（如 attachToParent）在不同子类中有所不同，则需要调整 BindingCreator 接口或 BindingElement 构造器，以允许子类传递这些特定参数。

总结

通过巧妙地结合Java 8的函数式接口和方法引用，我们能够以一种安全、优雅且高效的方式来组织和重用具有相似初始化逻辑的代码。这种模式不仅解决了传统面向对象设计中“构造器中调用虚方法”的陷阱，还提升了代码的模块化、可读性和可维护性。在处理类似的初始化场景时，优先考虑使用这种函数式编程与面向对象设计相结合的模式，将有助于构建更加健壮和灵活的Java应用程序。