Uma maneira de retornar vários valores de retorno de um método: coloque o método dentro da classe que representa o valor de retorno. É um bom design?

Eu preciso retornar 2 valores de um método. Minha abordagem é a seguinte:

1. crie uma classe interna com 2 campos que serão usados ​​para manter esses 2 valores
2. coloque o método dentro dessa classe
3. instanciar a classe e chamar o método

A única coisa que será alterada no método é que, no final, ele atribuirá esses 2 valores aos campos da instância. Então eu posso abordar esses valores fazendo referência aos campos desse objeto.

É um bom design e por quê?

Eu argumentaria isso da seguinte maneira:

• Por que exatamente seu método retorna vários valores? De que tipo de coesão estamos falando - esses valores devem realmente ser campos em uma única classe ou são retornados apenas por coincidência pelo mesmo método, mas não relacionados? Se for o último, convém dividir o método em dois métodos. Editar: use seu julgamento aqui; Às vezes, um tipo de coesão "coincidente" pode ser a melhor opção. Outra opção é usar uma construção de par ou de tupla, embora em OOP, elas geralmente não sejam vistas em APIs públicas (algumas exceções notáveis ​​são coleções padrão, etc.).
• Se os valores merecem formar uma classe, eu provavelmente desaconselharia o uso de uma classe interna. Classes internas são normalmente usadas como detalhes de implementação interna, ocultos do exterior. Existe alguma razão para que esse resultado não deva ser uma classe "completa", por si só?
• Além de manter dados, quais operações são aplicáveis ​​a essa nova classe? No design orientado a objetos, você deseja ter o comportamento relacionado próximo aos dados relevantes (que também parecem ser suas intenções). O método ao qual você está se referindo não deve residir nessa classe?

Para resumir, eu verificaria se posso transformar esse "objeto de dados" em uma classe avançada com dados e comportamento. Como um comentário adicional, convém tornar a classe imutável, pois seu estado é definido uma vez. Torná-lo imutável ajudará a evitar que seja definido incorretamente ou modificado posteriormente (digamos, alguém configurando um dos campos para nulo e passando adiante).

Edit: Como Patkos Csaba salienta corretamente, o princípio a ser aplicado aqui é o Single Responsability Principle ( SRP ) - a classe que você está tentando criar deve realmente ter uma responsabilidade (definida como uma razão para mudar ). Esta diretriz de design deve ajudá-lo a descobrir se seus dois campos pertencem a uma única classe ou não. Para ficar com o exemplo da Wikipedia, sua classe pode ser vista como um tipo de relatório; nesse caso, está em conformidade com o SRP, mas é difícil comentar sem mais informações.

Existe o conceito de uma tupla que é destaque em outros idiomas, como Python.

Pode-se retornar uma instância dessa classe genérica que é facilmente reutilizável:

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;
  }
}

Parece que esta classe está tirando a responsabilidade de outra classe, e isso me faz pensar que esse design não é ótimo.

Para um método que retorna valores multible, prefiro

• retornar um contêiner genérico (por exemplo, uma lista ou mapa) contendo os valores de retorno

ou

• crie uma classe para o valor de retorno, que contém apenas os campos necessários + getters + um construtor com todos os campos

Exemplo para a segunda opção:

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;
   }
}

Colocar vários valores de retorno de um método em sua própria classe / estrutura é frequentemente usado em sistemas baseados em mensagens que possuem uma classe para Solicitação e resposta . Um exemplo disso é o SOAP (Simple Object Access Protocol) .

É um bom design e por quê?

Pelo menos é bastante comum. Se isso é bom ou ruim, depende do seu caso de uso especial.

Resposta curta: você pode retornar uma matriz ou uma lista com os dois valores.

Eu pessoalmente escreveria dois métodos distintos, como

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