项目Reactor：以相同的顺序与另一个发布者反应性地转换可变对象的状态

Question

我正在尝试通过重构一些当前阻塞代码来学习反应式编程。我多次遇到在Mono序列中设置一些可变数据对象的状态而不订阅它的问题。在旧代码中，对象字段的值是由一些阻塞服务计算的，我现在也在Mono中这样做。

到目前为止，我通常（ab）使用持平地图来获得预期的行为：

java prettyprint-override">initExpensiveObject().flatMap(expObj -> initExpensiveField(expObj).map(expField -> {
    expObj.setExpensiveField(expField);
    return expObj;
})).subscribe(expObj -> System.out.println("expensiveField: " + expObj.getExpensiveField()));

import reactor.core.publisher.Mono;

public class Main {

    /**
     * Expensive, lazy object instantiation
     */
    public static Mono<ExpensiveObject> initExpensiveObject() {
        return Mono.fromCallable(ExpensiveObject::new);
    }

    /**
     * Expensive, async mapping (i.e. database access, network request):
     * ExpensiveObject -> int
     */
    public static Mono<Integer> initExpensiveField(ExpensiveObject expObj) {
        return Mono.just(1);
    }

    public static class ExpensiveObject {
        private int expensiveField = -1;

        public int getExpensiveField() {
            return expensiveField;
        }

        public void setExpensiveField(int expensiveField) {
            this.expensiveField = expensiveField;
        }
    }
}

虽然这种< code > flat map -模式有效，但我觉得应该有一种更具反应性的解决方案。考虑到仅在< code>Mono中就有如此多的操作符，为了改变其状态而从一个对象“映射”到同一个对象，直觉上感觉是错误的。然而，“副作用”操作符(< code>doOn*)不允许在没有订阅的情况下轻易转换另一个发布者。

如果我的问题没有微不足道的解决方案，我非常愿意接受设计改进，因为代码的设计仍然是顺序的。

Answer 1

虽然这种平面图模式有效，但我觉得应该有一种更具反应性的解决方案。

这可能不是你想听到的答案，但是反应性的解决方案是完全抛弃可变性。在更复杂的例子中，在反应链中传递可变对象可能会导致意外的副作用，这可能会导致一些很难跟踪的错误。完全重构可变性要容易得多。

如果我的问题没有微不足道的解决方案，我非常愿意进行设计改进

我认为“最少变化”的方法是:

• Make ExpensiveObject immutable. Remove the setter method, and provide another constructor that takes an explicit value for expensiveField.
• Provide a "reactive" withExpensiveField() (or ofExpensiveField(), or something else entirely, take your pick!) method on ExpensiveObject that takes a Mono<Integer> for expensiveField and returns a Mono<ExpensiveObject>.
• This then allows you to build your reactive chain with a single flatMap() call, and no mutable objects in sight:

  initExpensiveObject()
          .flatMap(expObj -> expObj.withExpensiveField(initExpensiveField(expObj)))
          .subscribe(expObj -> System.out.println("expensiveField: " + expObj.getExpensiveField()));
  

  上面的代码有修改：

  public class Main {
  
      /**
       * Expensive, lazy object instantiation
       */
      public static Mono<ExpensiveObject> initExpensiveObject() {
          return Mono.fromCallable(ExpensiveObject::new);
      }
  
      /**
       * Expensive, async mapping (i.e. database access, network request):
       * ExpensiveObject -> int
       */
      public static Mono<Integer> initExpensiveField(ExpensiveObject expObj) {
          return Mono.just(1);
      }
  
      public static final class ExpensiveObject {
  
          private final int expensiveField;
  
          public ExpensiveObject() {
              expensiveField = -1;
          }
  
          private ExpensiveObject(int expensiveField) {
              this.expensiveField = expensiveField;
          }
  
          public int getExpensiveField() {
              return expensiveField;
          }
  
          public Mono<ExpensiveObject> withExpensiveField(Mono<Integer> expensiveField) {
              return expensiveField.map(ExpensiveObject::new);
          }
      }
  }
  

  您可能希望根据最终设计更改上述内容（例如，方法在单个字段对象上没有多大意义），但这会跨越主要思想。