Dovrebbe essere creato un metodo che si limita a delegare a un costruttore?

Il secondo approccio nasconde la dipendenza su Pair , che può essere o non essere desiderabile.

Per decidere quale è meglio, dovresti sapere cosa è più probabile per l'utente di quel metodo: avere un oggetto Pair già costruito o avere i suoi pezzi singoli, perché è lì che la differenza tra due sovraccarichi saranno significativi.

Se è più o meno altrettanto probabile incontrare entrambe le situazioni, è più sensato avere entrambe le versioni del metodo.

if it is not to maintain an existing API?

Tieni presente che stai creando qui una tua API e anche la coerenza è importante. Un utente della tua API potrebbe avere l'impressione di aspettarsi che il sovraccarico sia presente ogni volta che è necessario un Pair . A seconda di quanto stai usando Pair in tutta la tua API, potrebbe essere un po 'di lavoro. E potrebbe esserci manutenzione necessaria in seguito.

Mi concentro sempre su come viene usato il codice. Ti piacerebbe andare usando:

foo.method(new Pair(str, obj));

Per usare:

foo.method(str, obj);

A cui dico: foo e method sono nomi terribili! Almeno so cos'è un Pair .

Con ciò intendo dire che sarebbe molto più facile vedere quanto è buona questa idea se si usassero nomi migliori. L'overloading del metodo è facile da impazzire. Il modo migliore che conosco per rallentare è quello di fermarmi e scegliere dei nomi significativi. Due di questi sono i primi:

foo.ofPair(new Pair(str, obj));

foo.put(str, obj);

Ora, solo io sapevo cosa fosse veramente questo foo .

Chiamerei questo una chiamata di convenienza. E credo che sia perfettamente bello averli. Almeno per i casi d'uso che sono davvero necessari più e più volte.

Le conversazioni di buona convenienza riducono in modo significativo la complessità di molti siti di chiamata senza introdurre alcuna complessità aggiuntiva. Dopo tutto, entrambi sono la stessa funzione, vogliono solo avere i loro parametri in un formato diverso.

L'unica cosa di cui devi occuparti è che entrambi i sovraccarichi hanno davvero un senso in sé e per sé. Se hai un call-through void foo() { member.foo(); } , questo potrebbe non essere giustificato se l'azione foo non ha senso per la classe contenitore stessa anche se la maggior parte dei casi d'uso chiamerebbe effettivamente container.member.foo() . Il punto è di mantenere chiaro l'intento delle funzioni.

Ci sono tre cose che ti vengono in mente come considerazioni su questa domanda:

• Standard di sviluppo
• Maintainability
• precisione del modello

Nella fase di sviluppo la tua decisione può stabilire una precedenza, e quindi standard, per il progetto di sviluppo del software. Cioè, se hai intenzione di seguire un particolare costrutto o schema di codifica in un posto, allora "dovresti" farlo ovunque. Potrebbe essere necessario tornare indietro attraverso la base di codice esistente per implementare lo stesso modello. Questa coerenza dello standard ridurrà il carico di supporto.

La considerazione nella fase di manutenzione richiede di formarsi un'opinione sulla capacità del team di manutenzione del software. Quale modello sarà più comprensibile dal team di supporto? Soprattutto, mi sarà comprensibile da parte tua in futuro.

A volte la scelta del costrutto del linguaggio di programmazione indica che il modello oggetto ha un errore. L'esempio che fornisci implica che la classe genitrice abbia una proprietà che è una coppia e che la proprietà pair sia proprietaria del metodo. Quando si modifica il modello a oggetti, il problema di programmazione scompare.

For example, if I have a method public void method(Pair<String, Object> pair){ ... }

Should I create the method public void method(String str, Object obj){ this.method(new Pair<>(str, obj); }

No. Perché ora hai due funzioni, entrambe chiamate method , che fanno due cose diverse. Invece, dai un nome alla seconda funzione qualcosa come:

public void createPairFromComponentsThenMethod(String str, Object obj){
    this.method(new Pair<>(str, obj); 
}