Esiste uno schema di progettazione con lo scopo di evitare confusione nella firma?

Question

Esiste uno schema di progettazione con lo scopo di evitare confusione nella firma?

#1 da (1 voti)

1

Per evitare confusione all'interno di una firma di metodo composta dagli stessi tipi, è possibile introdurre una classe per renderla distinguibile dagli altri.

Consentitemi di supportare una descrizione testuale con un esempio in Java.

Ad es., da:

public void foo(String bar, String baz, String qux, String quux);

a:

public void foo(Bar bar, Baz baz, Qux qux, Quux quux);

con le definizioni di classe come la seguente:

public final class Bar {

    private String bar;

    public String getBar() {
        return bar;
    }

    public void setBar(String bar) {
        this.bar = bar;
    }
}

Esiste un nome per un modello di progettazione simile o simile?

api-design design-patterns

posta Pavel 15.03.2018 - 03:41

fonte

1 risposta

Leggi altre domande sui tag api-design design-patterns

Mappatura di entità a macchine virtuali e ritorno: dovremmo usare l'overloading o il costruttore dell'operatore + un metodo di conversione? Uso delle classi interne per ottenere comportamenti thread-safe senza sincronizzazione

score 1 · Accepted Answer

Qui ci sono due possibili casi e sfortunatamente il tuo esempio è troppo semplificato per dire quale dei due si applica alla tua domanda:

I tipi di parametro rappresentano un concetto di dominio.
I parametri in realtà sono String s.

Nel caso # 1, i tipi non avrebbero dovuto essere String s per cominciare, avrebbero dovuto essere tipi di dominio, come FirstName , LastName o Address . Darren Hobbs chiama questo Modello di tipi minuscoli , ma in realtà, è solo design corretto.

Nel caso # 2, quello che stai proponendo è semplicemente sbagliato. I parametri sono String s, quindi il loro tipo dovrebbe essere String .

Tuttavia, almeno nel caso # 2, è altamente probabile che questo pezzo di codice viola altre linee guida di buon design e, ad esempio, sta facendo troppo lavoro. Oppure, i parametri hanno effettivamente una relazione tra loro e non devono essere parametri separati ma piuttosto un oggetto.

Ti sfido a dare un esempio reale di un metodo che prende il 4% diString s come parametri e non viola il buon design da qualche parte. Potresti voler leggere la discussione sulla Zero, One, Infinity Rule sul Wiki . @Steve Chamaillard ha menzionato la relazione con Oggetto Callisthenics nel suo commento.

Nota: Come @Derek Elkins menzionato nel suo commento , il fatto che hai reso i tuoi tipi di wrapper mutabili mentre il tipo originale ( String ) è immutabile, completamente cambia la semantica del codice! Nella mia risposta, suppongo che questo errore sia stato corretto e che il setter sia stato rimosso. (Esaminando qui il territorio molto supponente, suggerisco che non dovresti mai avere setter, punto.)