Dovremmo evitare oggetti personalizzati come parametri?

Supponiamo che io abbia un oggetto personalizzato, Studente :

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

E una classe, Finestra , che viene utilizzato per visualizzare le informazioni di uno Studente :

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

Sembra abbastanza normale, ma ho scoperto che Window non è abbastanza facile da testare individualmente, perché ha bisogno di un vero oggetto Student per chiamare la funzione. Quindi provo a modificare showInfo in modo che non accetti direttamente un oggetto Student :

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

in modo che sia più semplice testare Window singolarmente:

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

Ma ho scoperto che la versione modificata presenta altri problemi:

1. Modifica Studente (ad esempio: aggiungi nuove proprietà) richiede la modifica della firma del metodo di showInfo

2. Se Student avesse molte proprietà, la firma del metodo di Student sarebbe molto lunga.

Quindi, usando oggetti personalizzati come parametro o accettando ogni proprietà negli oggetti come parametro, quale è più gestibile?

L'uso di un oggetto personalizzato per raggruppare i parametri correlati è in realtà un modello consigliato. Come refactoring, si chiama Introduce Parameter Object .

Il tuo problema sta altrove. In primo luogo, il generico non Windowdovrebbe sapere nulla di Student. Invece, dovresti avere un tipo di StudentWindowciò che sa solo della visualizzazione Students. In secondo luogo, non vi è assolutamente alcun problema nella creazione Studentdell'istanza da testare StudentWindowpurché Studentnon contenga alcuna logica complessa che complicherebbe drasticamente i test StudentWindow. Se ha quella logica, allora Studentè preferibile creare un'interfaccia e deriderla.

Dici che lo è

non abbastanza facile da testare individualmente, perché ha bisogno di un vero oggetto Student per chiamare la funzione

Ma puoi semplicemente creare un oggetto studente da passare alla tua finestra:

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

Non sembra molto più complesso da chiamare.

In parole povere:

• Quello che chiami un "oggetto personalizzato" di solito è semplicemente chiamato un oggetto.
• Non è possibile evitare il passaggio di oggetti come parametri durante la progettazione di programmi o API non banali o l'utilizzo di API o librerie non banali.
• È perfettamente OK passare oggetti come parametri. Dai un'occhiata all'API Java e vedrai molte interfacce che ricevono oggetti come parametri.
• Le classi nelle biblioteche che usi dove sono state scritte da semplici mortali come te e me, quindi quelle che scriviamo non sono "personalizzate" , lo sono e basta.

Modificare:

Come afferma @ Tom.Bowen89 , non è molto più complesso testare il metodo showInfo:

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

1. Nel tuo esempio di studente suppongo che sia banale chiamare il costruttore Studente per creare uno studente da trasmettere a showInfo. Quindi non ci sono problemi.
2. Supponendo che l'esempio Studente sia deliberatamente banalizzato per questa domanda ed è più difficile da costruire, allora potresti usare un doppio di prova . Ci sono una serie di opzioni per doppi di prova, beffe, tronconi ecc. Di cui si parla nell'articolo di Martin Fowler tra cui scegliere.
3. Se si desidera rendere la funzione showInfo più generica, è possibile farla scorrere sulle variabili pubbliche, o forse gli accessi pubblici dell'oggetto passati ed eseguire la logica dello spettacolo per tutti. Quindi potresti passare qualsiasi oggetto conforme a quel contratto e funzionerebbe come previsto. Questo sarebbe un buon posto per usare un'interfaccia. Ad esempio, passare un oggetto Showable o ShowInfoable alla funzione showInfo in grado di mostrare non solo le informazioni sugli studenti, ma anche le informazioni di qualsiasi oggetto che implementano l'interfaccia (ovviamente quelle interfacce hanno bisogno di nomi migliori a seconda di come si desidera passare l'oggetto specifico o generico essere e ciò che uno studente è una sottoclasse di).
4. Spesso è più semplice passare in rassegna le primitive, e talvolta è necessario per le prestazioni, ma più puoi raggruppare concetti simili insieme più sarà comprensibile il tuo codice. L'unica cosa a cui fare attenzione è cercare di non esagerare e finire con il fizzbuzz aziendale .

Steve McConnell in Code Complete ha affrontato proprio questo problema, discutendo i vantaggi e gli svantaggi del passaggio di oggetti nei metodi invece di utilizzare le proprietà.

Perdonami se sbaglio alcuni dei dettagli, sto lavorando a memoria poiché è passato più di un anno da quando ho avuto accesso al libro:

Arriva alla conclusione che è meglio non usare un oggetto, invece di inviare solo quelle proprietà assolutamente necessarie per il metodo. Il metodo non dovrebbe sapere nulla sull'oggetto al di fuori delle proprietà che utilizzerà come parte delle sue operazioni. Inoltre, nel tempo, se l'oggetto viene mai modificato, ciò potrebbe avere conseguenze indesiderate sul metodo che utilizza l'oggetto.

Inoltre ha affrontato il fatto che se si finisce con un metodo che accetta molti argomenti diversi, probabilmente questo è un segno che il metodo sta facendo troppo e dovrebbe essere suddiviso in metodi più piccoli.

Tuttavia, a volte, a volte, in realtà hai bisogno di molti parametri. L'esempio che fornisce sarebbe di un metodo che costruisce un indirizzo completo, usando molte proprietà dell'indirizzo diverse (sebbene ciò possa essere ottenuto usando una matrice di stringhe quando ci pensate).

È molto più facile scrivere e leggere i test se si passa l'intero oggetto:

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() {
        ...
    }
}

Per confronto,

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

la riga potrebbe essere scritta, se passi valori separatamente, come:

showAStudentWithAFailingGrade(view);

dove la vera chiamata del metodo è sepolta da qualche parte

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

Per essere al punto, che non è possibile mettere la prova del metodo effettivo nel test è un segno che l'API è errata.

Dovresti passare ciò che ha senso, alcune idee:

Più facile da testare. Se gli oggetti devono essere modificati, cosa richiede il minimo refactoring? Riutilizzare questa funzione per altri scopi è utile? Qual è la quantità minima di informazioni di cui ho bisogno per dare questa funzione per fare il suo scopo? (Rompendolo - può farti riutilizzare questo codice - diffidare di cadere nel buco di progettazione di fare questa funzione e quindi di strozzare tutto per usare esclusivamente questo oggetto.)

Tutte queste regole di programmazione sono solo guide per farti pensare nella giusta direzione. Basta non costruire un codice bestia - se non sei sicuro e devi solo procedere, scegli una direzione / il tuo o un suggerimento qui, e se colpisci un punto in cui pensi 'oh, avrei dovuto farlo modo "- probabilmente puoi quindi tornare indietro e rifattorarlo abbastanza facilmente. (Ad esempio, se si dispone di una classe Insegnante, richiede solo la stessa proprietà impostata come Studente e si cambia la funzione per accettare qualsiasi oggetto del modulo Persona)

Sarei più propenso a mantenere l'oggetto principale passato, perché come codifico spiegherà più facilmente cosa sta facendo questa funzione.

Un percorso comune attorno a questo è quello di inserire un'interfaccia tra i due processi.

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) {

    }
}

Questo a volte diventa un po 'confuso ma le cose diventano un po' più ordinate in Java se usi una 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;
            }

        };
    }
}

Puoi quindi testare la Windowclasse semplicemente assegnandole un HasInfooggetto falso .

Sospetto che questo sia un esempio del motivo decorativo .

aggiunto

Sembra esserci un po 'di confusione causata dalla semplicità del codice. Ecco un altro esempio che può dimostrare meglio la tecnica.

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) {

    }
}

Hai già molte risposte valide, ma qui ci sono alcuni suggerimenti che potrebbero permetterti di vedere una soluzione alternativa:

• Il tuo esempio mostra uno Studente (chiaramente un oggetto modello) che viene passato a una Finestra (apparentemente un oggetto a livello di vista). Un oggetto Controller o Presentatore intermedio può essere utile se non ne hai già uno, consentendoti di isolare l'interfaccia utente dal tuo modello. Il controller / presentatore deve fornire un'interfaccia che può essere utilizzata per sostituirlo per i test dell'interfaccia utente e deve utilizzare le interfacce per fare riferimento agli oggetti del modello e visualizzare gli oggetti per essere in grado di isolarli da entrambi per il test. Potrebbe essere necessario fornire un modo astratto per crearli o caricarli (ad esempio oggetti Factory, oggetti Repository o simili).

• Il trasferimento di parti pertinenti degli oggetti modello in un oggetto trasferimento dati è un approccio utile per l'interfacciamento quando il modello diventa troppo complesso.

• È possibile che il tuo studente violi il principio di segregazione dell'interfaccia. In tal caso, potrebbe essere utile suddividerlo in più interfacce con cui è più facile lavorare.

• Il caricamento lento può semplificare la costruzione di grafici di oggetti di grandi dimensioni.

Questa è in realtà una domanda decente. Il vero problema qui è l'uso del termine generico "oggetto", che può essere un po 'ambiguo.

Generalmente, in un linguaggio OOP classico, il termine "oggetto" è diventato "istanza di classe". Le istanze di classe possono essere piuttosto pesanti: proprietà pubbliche e private (e quelle intermedie), metodi, eredità, dipendenze, ecc. Non vorrai davvero usare qualcosa del genere per passare semplicemente in alcune proprietà.

In questo caso, stai usando un oggetto come contenitore che contiene semplicemente alcune primitive. In C ++, oggetti come questi erano noti come structs(ed esistono ancora in linguaggi come C #). Le strutture erano, infatti, progettate esattamente per l'uso di cui parli: raggruppavano oggetti e primitivi correlati quando avevano una relazione logica.

Tuttavia, nei linguaggi moderni, non c'è davvero alcuna differenza tra una struttura e una classe quando scrivi il codice , quindi stai bene usando un oggetto. (Dietro le quinte, tuttavia, ci sono alcune differenze di cui dovresti essere consapevole - per esempio, una struttura è un tipo di valore, non un tipo di riferimento.) Fondamentalmente, finché manterrai il tuo oggetto semplice, sarà facile per testare manualmente. I linguaggi e gli strumenti moderni ti consentono di mitigarlo un po ', però (tramite interfacce, framework di simulazione, iniezione di dipendenza, ecc.)