Перечисления Java: два типа перечислений, каждый из которых содержит ссылки друг на друга?

Проблема не столько в том, что «два перечисления ссылаются друг на друга», сколько в том, что «два перечисления ссылаются друг на друга в своих конструкторах ». Эта круговая ссылка представляет собой сложную часть.

Как насчет использования методов Foo.setResponse (Bar b) и Bar.setResponse (Foo f) ? Вместо того, чтобы устанавливать Foo's Bar в конструкторе Foo (и аналогично Bar's Foo в конструкторе Bar), вы выполняете инициализацию с помощью метода? Например:

Foo:

public enum Foo {
  A, B, C;

  private void setResponse(Bar b) {
    this.b = b;
  }

  private Bar b;

  public Bar getB() {
    return b;
  }

  static {
    A.setResponse(Bar.Alpha);
    B.setResponse(Bar.Delta);
    C.setResponse(Bar.Alpha);
  }
}

Bar:

public enum Bar {
  Alpha, Beta, Delta;

  private void setResponse(Foo f) {
    this.f = f;
  }

  private Foo f;

  public Foo getF() {
    return f;
  }

  static {
    Alpha.setResponse(Foo.A);
    Beta.setResponse(Foo.C);
    Delta.setResponse(Foo.C);
  }
}

Также вы упомянули, что Foo и Bar - это два типа сообщений. Можно ли их объединить в один вид? Насколько я могу судить, их поведение здесь такое же. Это не исправляет круговую логику, но может дать вам другое представление о вашем дизайне ...

Поскольку кажется, что вы все равно будете жестко кодировать, почему бы не иметь что-то вроде

public static Bar responseBar(Foo f) {
 switch(f) {
  case A: return Bar.Alpha;
  // ... etc
 }
}

для каждого перечисления? Похоже, что в вашем примере у вас есть несколько перекрывающихся ответов, так что вы даже можете воспользоваться случаем, проваливающимся.

EDIT:

Мне нравится предложение Тома о EnumMap; Я думаю, что производительность , вероятно, выше на EnumMap, но вид элегантной конструкции, описанной в Effective Java, похоже, не обеспечивается этой конкретной проблемой - однако предложенное выше решение переключения было бы хорошим способом для создания двух статических EnumMaps ответ может быть примерно таким:

 public static Bar response(Foo f) { return FooToBar.get(f); }
 public static Foo response(Bar b) { return BarToFoo.get(b); }

Интересный дизайн. Я вижу вашу потребность, но что вы собираетесь делать, когда требования немного изменятся, так что в ответ на Foo.Epsilon приложение_1 должно отправить либо Bar.Gamma, либо Bar.Whatsit?

Решение, которое вы сочли и отвергли как хакерское (размещение отношения на карте), похоже, дадут вам большую гибкость и позволят избежать циклических ссылок. Это также сохраняет ответственность разделенной: сами типы сообщений не должны отвечать за знание своего ответа, не так ли?