Devemos evitar objetos personalizados como parâmetros?

Suponha que eu tenha um objeto personalizado, Student :

public class Student{
    public int _id;
    public String name;
    public int age;
    public float score;
}

E uma classe, Window , usada para mostrar informações de um Aluno :

public class Window{
    public void showInfo(Student student);
}

Parece bastante normal, mas achei que o Window não é muito fácil de testar individualmente, porque ele precisa de um objeto Student real para chamar a função. Então, eu tento modificar showInfo para que ele não aceite um objeto Student diretamente:

public void showInfo(int _id, String name, int age, float score);

para que seja mais fácil testar o Window individualmente:

showInfo(123, "abc", 45, 6.7);

Mas eu achei que a versão modificada tem outros problemas:

1. Modificar Aluno (por exemplo: adicionar novas propriedades) requer a modificação da assinatura do método showInfo

2. Se o Student tivesse muitas propriedades, a assinatura do método seria muito longa.

Então, usando objetos personalizados como parâmetro ou aceite cada propriedade em objetos como parâmetro, qual é mais sustentável?

Usar um objeto personalizado para agrupar parâmetros relacionados é, na verdade, um padrão recomendado. Como refatoração, é chamado de Introduzir Objeto de Parâmetro .

Seu problema está em outro lugar. Primeiro, o genérico não Windowdeve saber nada sobre o Student. Em vez disso, você deve StudentWindowsaber que apenas a exibição é exibida Students. Segundo, não há absolutamente nenhum problema em criar uma Studentinstância para testar StudentWindow, desde Studentque não contenha nenhuma lógica complexa que complicaria drasticamente o teste StudentWindow. Se ele tiver essa lógica, Studenté preferível criar uma interface e zombar.

Você diz que é

não é muito fácil testar individualmente, porque ele precisa de um objeto Student real para chamar a função

Mas você pode simplesmente criar um objeto de aluno para passar para sua janela:

showInfo(new Student(123,"abc",45,6.7));

Não parece muito mais complexo ligar.

Em termos leigos:

• O que você chama de "objeto personalizado" geralmente é chamado de objeto.
• Não é possível evitar a passagem de objetos como parâmetros ao projetar qualquer programa ou API não trivial ou ao usar qualquer API ou biblioteca não trivial.
• Não há problema em passar objetos como parâmetros. Dê uma olhada na API Java e você verá muitas interfaces que recebem objetos como parâmetros.
• As classes nas bibliotecas que você usa foram escritas por meros mortais como você e eu; portanto, as que escrevemos não são "personalizadas" , apenas são.

Editar:

Como @ Tom.Bowen89 afirma, não é muito mais complexo testar o método showInfo:

showInfo(new Student(8812372,"Peter Parker",16,8.9));

1. No seu exemplo de aluno, presumo que seja trivial chamar o construtor Student para criar um aluno para passar para showInfo. Portanto, não há problema.
2. Assumindo o exemplo, o aluno é deliberadamente banalizado para esta pergunta e é mais difícil de construir, então você pode usar um teste duplo . Existem várias opções para duplas de teste, zombarias, stubs, etc. mencionadas no artigo de Martin Fowler para você escolher.
3. Se você quiser tornar a função showInfo mais genérica, pode iterá-la sobre as variáveis ​​públicas, ou talvez os acessadores públicos do objeto passem e executem a lógica de exibição para todas elas. Em seguida, você poderia passar qualquer objeto que estivesse em conformidade com esse contrato e ele funcionaria conforme o esperado. Este seria um bom lugar para usar uma interface. Por exemplo, passe um objeto Showable ou ShowInfoable para a função showInfo que possa mostrar não apenas informações de alunos, mas informações de qualquer objeto que implemente a interface (obviamente essas interfaces precisam de nomes melhores, dependendo de quão específico ou genérico você deseja que o objeto possa ser transmitido. ser e de que aluno é uma subclasse).
4. Muitas vezes, é mais fácil repassar primitivas e, às vezes, necessárias para o desempenho, mas quanto mais você agrupar conceitos semelhantes, mais compreensível será o seu código. A única coisa a observar é tentar não exagerar e acabar com o fracasso da empresa .

Steve McConnell, do Code Complete, abordou esse problema, discutindo os benefícios e as desvantagens de passar objetos para métodos em vez de usar propriedades.

Perdoe-me se eu entendi errado alguns detalhes, estou trabalhando de memória, pois já faz mais de um ano desde que tive acesso ao livro:

Ele chega à conclusão de que é melhor você não usar um objeto, enviando apenas as propriedades absolutamente necessárias para o método. O método não precisa saber nada sobre o objeto fora das propriedades que ele usará como parte de suas operações. Além disso, com o tempo, se o objeto for alterado, isso poderá ter consequências indesejadas no método usando o objeto.

Ele também abordou que, se você acabar com um método que aceita muitos argumentos diferentes, isso provavelmente é um sinal de que o método está fazendo muito e deve ser dividido em mais métodos menores.

No entanto, às vezes, às vezes, você realmente precisa de muitos parâmetros. O exemplo que ele dá seria de um método que constrói um endereço completo, usando muitas propriedades de endereço diferentes (embora isso possa ser contornado usando uma matriz de cadeias de caracteres quando você pensa sobre isso).

É muito mais fácil escrever e ler testes se você passar o objeto inteiro:

public class AStudentView {
    @Test 
    public void displays_failing_grade_warning_when_a_student_with_a_failing_grade_is_shown() {
        StudentView view = aStudentView();
        view.show(aStudent().withAFailingGrade().build());
        Assert.that(view, displaysFailingGradeWarning());
    }

    private Matcher<StudentView> displaysFailingGradeWarning() {
        ...
    }
}

Para comparação,

view.show(aStudent().withAFailingGrade().build());

A linha pode ser escrita, se você passar valores separadamente, como:

showAStudentWithAFailingGrade(view);

onde a chamada de método real está enterrada em algum lugar como

private showAStudentWithAFailingGrade(StudentView view) {
    int someId = .....
    String someName = .....
    int someAge = .....
    // why have been I peeking and poking values I don't care about
    decimal aFailingGrade = .....
    view.show(someId, someName, someAge, aFailingGrade);
}

Para chegar ao ponto, que você não pode colocar a chamada de método real no teste é um sinal de que sua API está incorreta.

Você deve passar o que faz sentido, algumas idéias:

Mais fácil de testar. Se o (s) objeto (s) precisam ser editados, o que requer menos refatoração? É útil reutilizar esta função para outros fins? Qual é a menor quantidade de informações que preciso fornecer a essa função para realizar seu objetivo? (Ao dividi-lo - pode permitir que você reutilize esse código - tenha cuidado para não cair no buraco do design de fazer essa função e depois gargalhar tudo para usar exclusivamente esse objeto.)

Todas essas regras de programação são apenas guias para você pensar na direção certa. Apenas não construa uma besta de código - se você não tiver certeza e precisar prosseguir, escolha uma direção / sua ou uma sugestão aqui, e se você chegar a um ponto em que pensa 'oh, eu deveria ter feito isso caminho '- você provavelmente pode voltar e refatorá-lo facilmente. (Por exemplo, se você tem turma de professor - ela precisa da mesma propriedade definida como Aluno e você muda sua função para aceitar qualquer objeto do formulário Pessoa)

Eu estaria mais inclinado a manter o objeto principal sendo transmitido - porque como eu codifico, ele explica mais facilmente o que essa função está fazendo.

Uma rota comum para contornar isso é inserir uma interface entre os dois processos.

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

interface HasInfo {
    public String getInfo();
}

public class StudentInfo implements HasInfo {
    final Student student;

    public StudentInfo(Student student) {
        this.student = student;
    }

    @Override
    public String getInfo() {
        return student.name;
    }

}

public class Window {

    public void showInfo(HasInfo info) {

    }
}

Às vezes, isso fica um pouco confuso, mas as coisas ficam um pouco mais organizadas em Java se você usar uma classe interna.

interface HasInfo {
    public String getInfo();
}

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;

    public HasInfo getInfo() {
        return new HasInfo () {
            @Override
            public String getInfo() {
                return name;
            }

        };
    }
}

Em seguida, você pode testar a Windowclasse dando a ela um HasInfoobjeto falso .

Suspeito que este seja um exemplo do Padrão Decorador .

Adicionado

Parece haver alguma confusão causada pela simplicidade do código. Aqui está outro exemplo que pode demonstrar melhor a técnica.

interface Drawable {

    public void Draw(Pane pane);
}

/**
 * Student knows nothing about Window or Drawable.
 */
public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

/**
 * DrawsStudents knows about both Students and Drawable (but not Window)
 */
public class DrawsStudents implements Drawable {

    private final Student subject;

    public DrawsStudents(Student subject) {
        this.subject = subject;
    }

    @Override
    public void Draw(Pane pane) {
        // Draw a Student on a Pane
    }

}

/**
 * Window only knows about Drawables.
 */
public class Window {

    public void showInfo(Drawable info) {

    }
}

Você já tem muitas respostas boas, mas aqui estão mais algumas sugestões que podem permitir que você veja uma solução alternativa:

• Seu exemplo mostra um Aluno (claramente um objeto de modelo) sendo passado para uma Janela (aparentemente um objeto no nível da visualização). Um objeto intermediário do Controller ou Presenter pode ser benéfico se você ainda não tiver um, permitindo que você isole a interface do usuário do seu modelo. O controlador / apresentador deve fornecer uma interface que possa ser usada para substituí-la no teste da interface do usuário e deve usar interfaces para se referir aos objetos de modelo e exibir objetos para poder isolá-lo dos dois para teste. Pode ser necessário fornecer uma maneira abstrata de criar ou carregar esses objetos (por exemplo, objetos de fábrica, objetos de repositório ou similares).

• Transferir partes relevantes dos objetos do modelo para um Objeto de Transferência de Dados é uma abordagem útil para fazer a interface quando o modelo se torna muito complexo.

• Pode ser que seu Aluno viole o Princípio de Segregação de Interface. Nesse caso, pode ser benéfico dividi-lo em várias interfaces mais fáceis de trabalhar.

• O Lazy Loading pode facilitar a construção de grandes gráficos de objetos.

Esta é realmente uma pergunta decente. O problema real aqui é o uso do termo genérico "objeto", que pode ser um pouco ambíguo.

Geralmente, em uma linguagem clássica de POO, o termo "objeto" passou a significar "instância de classe". As instâncias de classe podem ser bem pesadas - propriedades públicas e privadas (e as intermediárias), métodos, herança, dependências etc. Você realmente não gostaria de usar algo assim para simplesmente passar algumas propriedades.

Nesse caso, você está usando um objeto como um contêiner que simplesmente contém algumas primitivas. No C ++, objetos como esses eram conhecidos como structs(e ainda existem em linguagens como C #). As estruturas foram, de fato, projetadas exatamente para o uso que você fala - elas agrupavam objetos e primitivos relacionados quando tinham um relacionamento lógico.

No entanto, nas linguagens modernas, não há realmente nenhuma diferença entre uma estrutura e uma classe quando você está escrevendo o código ; portanto, você pode usar um objeto. (Nos bastidores, no entanto, há algumas diferenças das quais você deve estar ciente - por exemplo, uma estrutura é um tipo de valor, não um tipo de referência.) Basicamente, desde que você mantenha seu objeto simples, será fácil para testar manualmente. Porém, linguagens e ferramentas modernas permitem mitigar bastante isso (via interfaces, estruturas de simulação, injeção de dependência etc.)