Sposób na zwrócenie wielu zwracanych wartości z metody: umieść metodę w klasie reprezentującej zwracaną wartość. Czy to dobry projekt?

Muszę zwrócić 2 wartości z metody. Moje podejście jest następujące:

1. utwórz wewnętrzną klasę z 2 polami, które będą używane do zachowania tych 2 wartości
2. umieść metodę w tej klasie
3. utwórz instancję klasy i wywołaj metodę.

Jedyną rzeczą, która zostanie zmieniona w metodzie jest to, że ostatecznie przypisze te 2 wartości do pól instancji. Następnie mogę odnieść się do tych wartości, odwołując się do pól tego obiektu.

Czy to dobry projekt i dlaczego?

Argumentowałbym to w następujący sposób:

• Dlaczego dokładnie twoja metoda zwraca wiele wartości? O jakim rodzaju spójności mówimy - czy te wartości powinny faktycznie być polami w jednej klasie, czy też są przypadkowo zwracane tą samą metodą, ale poza tym niezwiązane? Jeśli jest to drugie, możesz rozważyć podzielenie metody na dwie metody. Edytuj: użyj tutaj oceny; czasami najlepszym rozwiązaniem jest rodzaj „przypadkowej” spójności. Inną opcją jest użycie konstrukcji parowej lub krotkowej, chociaż w OOP zwykle nie są one widoczne w publicznych interfejsach API (niektóre znaczące wyjątki to standardowe kolekcje itp.).
• Jeśli wartości zasługują na utworzenie klasy, prawdopodobnie odradzałbym używanie klasy wewnętrznej. Klasy wewnętrzne są zwykle używane jako wewnętrzne szczegóły implementacji, które są ukryte z zewnątrz. Czy jest jakiś powód, dla którego wynik ten nie powinien być klasą „w pełnym wymiarze”?
• Jakie operacje oprócz przechowywania danych mają zastosowanie do tej nowej klasy? W projektowaniu obiektowym chcesz, aby powiązane zachowanie było zbliżone do odpowiednich danych (które również wydają się być twoimi intencjami). Czy metoda, o której mówisz, nie powinna raczej żyć w tej klasie?

Podsumowując, chciałbym przekonać się, czy mogę przekształcić ten „obiekt danych” w rozwiniętą klasę z danymi i zachowaniem. Jako dodatkowy komentarz, możesz sprawić, by klasa była niezmienna, ponieważ jej stan jest ustawiany raz. Uczynienie go niezmiennym pomoże zapobiec niepoprawnemu ustawieniu lub modyfikacji w późniejszym czasie (powiedzmy, że ktoś ustawi jedno z pól na zero i przekaże je dalej).

Edycja: Jak słusznie zauważa Patkos Csaba, stosowana tutaj zasada to Zasada Jednej Odpowiedzialności ( SRP ) - klasa, którą próbujesz stworzyć, powinna mieć naprawdę jedną odpowiedzialność (zdefiniowaną jako powód zmiany ). Te wytyczne projektowe powinny pomóc ci dowiedzieć się, czy twoje dwa pola należą do jednej klasy, czy nie. Aby trzymać się przykładu z Wikipedii, twoja klasa może być postrzegana jako rodzaj raportu, w którym to przypadku jest zgodny z SRP, ale trudno jest skomentować bez dalszych informacji.

Istnieje koncepcja krotki, która występuje w innych językach, takich jak Python.

Można zwrócić instancję tej uogólnionej klasy, którą można łatwo ponownie wykorzystać:

public class TypedTuple<L, R> implements Serializable {
private static final long serialVersionUID = 1L;

  protected L left;
  protected R right;

  protected TypedTuple() {
    // Default constructor for serialization
  }

  public TypedTuple(L inLeft, R inRight) {
    left = inLeft;
    right = inRight;
  }

  public L getLeft() {
    return left;
  }

  public R getRight() {
    return right;
  }
}

Wygląda na to, że ta klasa odbiera odpowiedzialność innej klasie, a to sprawia, że ​​myślę, że ten projekt nie jest świetny.

W przypadku metody zwracającej wartości uniwersalne wolałbym

• zwraca ogólny kontener (np. Listę lub Mapę) zawierający zwracane wartości

lub

• utwórz klasę dla wartości zwracanej, która zawiera tylko niezbędne pola + gettery + konstruktor ze wszystkimi polami

Przykład dla drugiej opcji:

public Class FooBarRetval {
   private String foo;
   private int bar;

   public FooBarRetval (String foo, int bar) {
      this.foo = foo;
      this.bar = bar;
   }

   public String getFoo() {
      return foo;
   }

   public int getBar() {
      return bar;
   }
}

Wpisywanie wielu zwracanych wartości z metody do jej własnej klasy / struktury jest często stosowane w systemach opartych na komunikatach, które mają jedną klasę dla żądania i odpowiedzi . Przykładem tego jest protokół Simple Object Access Protocol (SOAP) .

Czy to dobry projekt i dlaczego?

Przynajmniej jest to dość powszechne. To, czy jest to dobre czy złe, zależy od twojego specjalnego przypadku użycia.

Krótka odpowiedź: możesz zwrócić tablicę lub listę z dwiema wartościami.

Osobiście napisałbym dwie różne metody

int x = obj.getX();
int y = obj.getY();