Il "Introduce Parameter Object" è in realtà un buon modello?

3

Ho una situazione in cui voglio chiamare una funzione che richiede un numero di parametri. Questa funzione non viene chiamata direttamente, viene chiamata indirettamente e i parametri vengono delegati più volte. Alcuni parametri aggiuntivi possono essere aggiunti tra i diversi livelli, ma quelli non sono inclusi nell'esempio per semplicità.

In pseudo codice, A chiama indirettamente la funzionalità che si verifica in C.abc .

class A {
    private B b;

    public int abc() {
        return b.abc(value1, value2, value3);
    }
}

class B {
    private C c;

    public int abc(int x, int y, int z) {
        return c.abc(x, y, z);
    }
}

class C {
    private int w = 100;

    public int abc(int x, int y, int z) {
        // Do something with parameters x, y, z, e.g.:
        return w + x + y + z;
    }
}

Il numero di parametri potrebbe essere diverso di tre, naturalmente: potrebbe essere più piccolo o più grande a condizione che i parametri vengano utilizzati insieme. Talvolta il Introduce Parameter Object viene consigliato in tale situazione ( qui e qui ).

Sarebbe applicato come segue:

class XYZParameterObject {

    private int x, y, z;

    public constructor(int x, int y, int z) {
        this.x = x;
        this.y = y;
        this.z = z;
    }

    public int abc(int w) {
        return w + x + y + z;
    }
}

class A {
    private B b;

    public int abc() {
        return b.abc(new XYZParameterObject(value1, value2, value3));
    }
}

class B {
    private C c;

    public int abc(XYZParameterObject xyz) {
        return c.abc(xyz);
    }
}

class C {
    private int w = 10;

    public int abc(XYZParameterObject xyz) {
        // Do something with parameters x, y, z, e.g.:
        return xyz.abc(this.w);
    }
}

Per me sembra che una classe sia progettata attorno a un solo metodo, mentre non ha alcun comportamento. In realtà sarebbe come passare una chiusura invece di creare un'istanza XYZParameterObject . In entrambe le situazioni i parametri x, y, z sono ridotti a un solo parametro. Entrambi sembrano abusare di una classe solo per non dover passare gli stessi argomenti più e più volte. D'altra parte, ciò sarebbe in qualche modo conveniente, naturalmente!

Quindi qual è una pratica consigliabile in una situazione del genere?

    
posta user2180613 30.08.2016 - 12:50
fonte

2 risposte

5

Un oggetto parametro è solo un modo per raccogliere un set di parametri in un'unità. Ma nel tuo esempio stai facendo qualcosa di più - stai aggiungendo la logica di business (l'aggiunta) nell'oggetto parametro stesso (che a sua volta significa che la classe C diventa superfluo). Ma poi non è più solo un oggetto parametro.

Un oggetto parametro non è una classe costruita attorno a un singolo metodo, è un oggetto di trasferimento dati, il che significa che non ha affatto metodi (o almeno solo metodi per accedere ai dati). Ma potrebbe essere il punto di partenza per una vera classe con metodi di business.

Se un oggetto parametro è una buona idea in primo luogo dipende dal codice. Il tuo esempio è troppo astratto per dirlo. Ma se x , y e z indicano le coordinate rappresentate per un punto in 3D, sarebbe probabilmente utile raggrupparle in un oggetto parametro, ma probabilmente anche utile aggiungere una logica aziendale per i calcoli sui punti, ad esempio ridimensionamento, aggiunta ecc.

    
risposta data 30.08.2016 - 13:27
fonte
0

Is “Introduce Parameter Object” actually a good pattern?

Sì. Sotto ogni aspetto.

Rende il codice più leggibile e di conseguenza più comprensibile: meno informazioni si devono analizzare, più facili da capire.

Da questo punto di vista, ha senso rifattare un elenco di parametri su un oggetto . E se assegni a questo oggetto un nome significativo, vinci il doppio.

Dopo la modifica:

To me this seems like a class is designed around just one method, while it does not have any behavior.

L'inserimento di un metodo nell'oggetto non ha senso (nel contesto che hai fornito) di senso.

Una chiamata a a.abc() delega la chiamata a b.abc() , che a sua volta fa qualcosa con i valori contenuti nel tuo oggetto valore. Quindi il luogo, a cui dovrebbe appartenere method , è il tuo esempio C .

Il metodo ha senso solo quando una chiamata ad esso deve essere riutilizzabile - diciamo che A ha bisogno del risultato per informare un possibile D su di esso.

So what is an advisable practice in such a situation?

Va bene, usare un oggetto valore anche allo scopo di accorciare semplicemente la lista dei parametri. Rende il codice più leggibile.

Aggiungi solo metodi, quando ci sono vantaggi in più di un posto da quello.

    
risposta data 30.08.2016 - 14:01
fonte

Leggi altre domande sui tag